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This thesis designs and implements an automated database system that can be used 
on the Hellenic navy ships. The methodology followed is the standard systems' 
development life cycle (SDLC). The requirements for the system are obtained, and the 
database and application are designed and implemented. Paradox is used for the database 
management system software. Special issues like training, security, conversion and 
maintenance are taken into consideration. 

The result of this thesis is a functional application named "SPAS" (Shipboard 
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L INTRODUCTION 



A. OBJECTIVE 

This thesis designs and implements a database system for the Hellenic Navy ships. 
The purpose of the system is to support all the administrative activities of the personnel 
assigned onboard. The implementation of the database system would greatly reduce the 
work hours spent on specific administrative tasks that are instrumental in accomplishing 
Hellenic Navy ships' principal tasks and maintaining an efficient operational level. The 
database design takes into consideration the Hellenic Navy ships' functional requirements. 
The primary function of the database system is to maintain the records of necessary 
personnel and other relevant information. From this database standard reports are 
generated, and ad hoc queries and reports are created. 

B. BACKGROUND 

In every battle ship the personnel should be organized in such a way that the ship 
can provide a variety of functions and operate under different situations in different 
environments. These functions are performed by the persons serving on the ship. The 
management of this personnel organization is a difficult and time-consuming job in terms 
of personnel data entry, maintenance of manually kept forms, determination and allocation 
of duties and handling personnel requests. Furthermore, the large volume of daily, weekly 
and monthly reports required either for submission to the higher command or for the 



ship's internal use, makes the personnel administration job very difficult. In addition, the 
command needs help in making decisions about subjects of an administrative nature: for 
example, having people process data in order to propose a suggestion is a time consuming 
task and might result in inaccurate and unreliable information. 

The ship consists of departments which are managed by the department heads, and 
divisions which are managed by the division officers. In the Hellenic Navy, only 
commissioned and non-commissioned officers serve on a permanent basis while seamen 
serve for a short standard period of time. Crewmember changes are based on annual 
occurrences. Seamen changes are based on the time served. From time to time projection 
tables must be sent to the Navy training centers for future needs of seamen assignments. 
The new seamen must first obtain training for special duties; then they have to be 
qualified by the division officer or the department head; finally they may get some 
additional training while they serve. 

To help the reader in what follows, the following are some brief explanations of 
terminology as applied in the Hellenic Navy: 

Port Duty Station is the assigned position in which every crewmember has to work 
while in port. 

Fitness Evaluation is a compulsory procedure for officers up to the rank of 
Lieutenant and Petty Officers up to 40 years old, in which they must pass an annual 
physical fitness test. 

Promotion is a promotion in rank. Seamen do not receive promotions, only Officers 
and Petty Officers do. The promotion can never exceed the following higher rank. 
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Disciplinary report comprises the crewmember's offense, apology, and punishment. 
A record of the date, nature of event, facts and everything related to the offense is kept. 

Crew division systems is how the crew is divided to perform onboard activities. 
There are two crew division systems. The first is called "Half Crew Division System" 
under which each crewmember is scheduled to work 6 hours and rest for 6 hours. The 
second work schedule is called "One Third Crew Division System" and has shifts of 4 
hours on and 8 hours off. The decision to adopt either one of the systems depends on the 
type of ship's operations being conducted. 

Leave designates the type of leave given to crewmembers. In addition, seamen 
serving onboard a ship have right to the so-called "sea duty leave". 

On the Job Training Evaluation (OJT) applies to Officers, Petty Officers and seamen 
who are all subject to OJT Evaluation. The evaluation occurs at regular intervals and is 
set by the Department Head or the Division Officer. If a member changes his position, 
the OJT Evaluation is automatically performed. 

Abandon Ship Station is the preassigned station in which every crewmember has 
to proceed once the order "Abandon Ship" has been given. 

The Armed Security Group is composed of an Officer as the leader and several 
Petty Officers and sailors; it has the predefined task of defending the ship against terrorist 
attacks or intruders. 

Change in Command is a change of role or duty in the Department or the Division 
for an Officer or a Petty Officer. 

Mooring, Anchoring, and Towing station are the areas where all personnel are 
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assigned to be while mooring, anchoring or towing is occurring. 

Training is the term that covers the training received in a school by an Officer, 
Petty Officer or seaman. 

A ir controller is an Officer or Petty Officer whose duty is to control all aircraft 
cooperating with the ship. 

Alert Station is the pre-assigned position of each crewmember under alert 
conditions. 

Replenishment at Sea Station is the station to which a specially trained team, led 
by an officer, proceeds when refueling at sea. The task of the RAS team is to take the 
necessary actions until refueling is over. 

XO's Daily Report Division is the division system in which crewmembers are 
gathered during the XO's daily morning report. 

C METHODOLOGY 

There are different methodologies for developing systems. The process that will be 
followed in this thesis captures the essence of most development methodologies. The 
fundamental phases are: 

• Definition phase: 

During the definition phase, the tasks are to form the working team, define 
the problem, establish the scope, and access feasibility issues. 

• Requirements phase 

During the requirements phase, the tasks are to create the user's data model, 
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determine the update, display, and control mechanisms, as well as the functional 
components of the application, interview the users, and use prototypes to help determine 
user requirements. 

• Evaluation phase 

During the evaluation phase, the tasks are to select the system's architecture, 
and reassess feasibility issues. 

• Design phase 

During the design phase, the tasks are to develop the database design and the 
application design. The database design consists of structuring the relations, and 
establishing the relationships among them. The application design, deals with the design 
of the menus, reports, and forms as well as to specify update, display, and control 
mechanisms. 

• Implementation phase 

During the implementation phase, the tasks are to construct the database, build 
the application, and install it. 

This System's Development Life Cycle was utilized in the development of the Shipboard 
Personnel Administration System (SPAS) of this thesis. 

D. CHAPTER OUTLINE 

The thesis is organized as follows: 

Chapter II is a general description of the database development process. It reviews 
database concepts, and describes the database development phases. These phases, the 
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requirements analysis and specification, the design, and the implementation, are detailed 
in the following chapters. 

Chapter III is the requirements analysis of the system. The operating environment 
is studied by means of the user's descriptive list of requirements for the system's 
functionality, data manipulation and production of specific information. The requirements 
and accompanied entity-relationship data flow diagrams are provided. The chapter 
concludes with a description of the requirements specifications as they pertain to data, 
hardware and software issues. 

Chapter IV describes the design process followed in developing the Shipboard 
Personnel Administration System ( SPAS ). The data and process models developed in 
the previous chapters are transformed into a relational and application design, respectively. 
The last section provides commentary about the data dictionary and its benefits to the 
database system design. 

Chapter V is a discussion of the final phases involved in developing the database 
system. These phases are the implementation portion of the data and process design and 
they include programming and planning for the system's implementation. 

Chapter VI deals with other important issues in developing the system such as 
testing, database security, personnel training, system conversion, maintenance and future 
upgrades. 

Chapter VII is the concluding chapter. It provides a short summary of the thesis 
and addresses future enhancements to the system developed. Also included are lessons 
learned in developing the system. 
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Appendices A through I supplement the previously described text. The appendices 
are: Object Diagrams, Data Dictionary, Data Flow Diagrams, Relational Schema, 
Application Menus, Application Input Forms, Application Reports, System's Program and 
Code and Procedures for installing and operating SPAS, respectively. 
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IL DATABASE DEVELOPMENT PROCESS 



In this chapter we will discuss basic database concepts as well as the database 
development methodology. Each step of the system's development methodology is 
described in some detail. 

A. DATABASE CONCEPTS 

The term database is subject to many different interpretations. It has been used to 
refer to everything from a collection of index cards to the volumes of data that a 
government collects about its citizens. In the following we will use this term with a 
specific meaning: A database is a self-describing collection of integrated records. 

1. A Database is Self-Describing 

In addition to the user's source data, a database contains a description of its 
own structure. This description is called the data dictionary, and makes program/data 
independence possible. In that way, by examining the database itself, it's easy to 
determine its structure and its components; no external documentation of file and record 
formats is needed. Furthermore, when changing data in the database, we only need to 
make corresponding changes to the data dictionary. 

2. A Database is a Collection of Integrated Records 

As shown in figure 1, a database is more than a collection of files. It includes 
source data, a description of the database structure (data dictionary), and a description of 
the relationships among the records of the files (overhead data). The mam difference 
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between a database and a file processing system is that a database is able to store these 
relationships. 




3. Components of a Database Processing System 

i 

A database processing system has five components as shown in figure 2. 



Bridge 




Figure 2: Components of a database processing system 

These are hardware, programs, data, procedures and people. The most important 
components are the people and the data. The data contain all the useful information that 
people need to perform their tasks and complete their activities. 
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B. DATABASE DEVELOPMENT METHODOLOGY 



The database development methodology described here consists of four phases: 
definition, requirements, evaluation, and design. Each phase consists of a number of 
tasks. 

During the definition phase the tasks are to form the working team, define the 
problem, establish the scope, and access feasibility issues. 

During the requirements phase, the tasks are to create the user's data model, as well 
as the functional components of the application. This is accomplished by interviewing 
the users, and using prototypes to help determine user requirements. 

During the evaluation phase, the tasks are to select the system's architecture, and 
reassess feasibility issues. 

During the design phase, the tasks are to develop the database design and the 
application design. The database design consists of structuring the relations, and the 
establishing relationships among them. The application design, deals with the design of 
the menus, reports, and forms. 

During the implementation phase, the tasks are to construct the database, build the 
application, and install it. 

The requirements, design, and implementation are detailed in the following sections. 

C. REQUIREMENTS ANALYSIS / SPECIFICATIONS 

Accurately obtaining the system's information requirements from the potential users 
is essential. No system can be designed without first understanding the current process 
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intended for improvement. After the system's definition and primary analysis phase, 
where the general goals of the system are determined, the requirements phase follows. 
The purpose of this phase is to determine, as specifically as possible, what the system 
must do. There are two tasks in this phase: 

• develop a user's data model 

• determine the functional components of each application that will use the 
database 

1. Data Requirements 

During the data requirements phase, the major goals are to build a data model 
that documents the "things" that are to be represented in the database, to determine the 
characteristics of those "things" that need to be stored and to determine the relationships 
among them. The user's data model describes the objects that must be stored in the 
database, along with their structure and the relationships that they have with one another. 
The output of the data requirements phase is a statement of requirements. This statement 
can take a variety of forms: a verbal description; an entity-relationship and objects 
diagrams; one or more prototypes; or any combination of the above. 

The "things" that are represented in the database are referred to as either entities or 
semantic objects (in some cases just objects) depending on the modeling technique that 
the designer follows. In this thesis the semantic object model will be followed 

A semantic object is a named collection of properties that sufficiently describes a 
distinct identity. Semantic object diagrams assist in the system analysis as well as the 
design phase. Some of the characteristics of semantic objects are: 
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• the semantic objects are grouped into classes; each class has a distinctive 
name; classes are shown in capital letters 

• an object is a collection of properties with a sufficient description 

• objects represent distinct identities 

• the identities that the objects represent may or may not have physical existence 
Objects have properties that define their characteristics. These properties can be 

simple property, composite of a group of properties, or another object. An object can 
have single or multiple values. In a semantic object diagram, objects are shown in boxes; 
their name appears beneath or above the rectangle and properties are written inside the 
rectangle. The "MV" symbol next to a property declares that this property can have 
multiple values. The non-object properties have scalar values while the object properties 
are separate objects by themselves. Figure 3 shows a sample object. 



Property 1 
Property 2 MV 



Property 3 



Property 4 



MV 



Figure 3: Sample Object 
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A property can take its value from a set of possible values; this set is called the 
domain of the property. The domain gives both the physical and the semantic description. 
The physical description indicates the type of data, the length of the property and 
probably some restrictions or constraints that may apply to the property. The semantic 
description describes the function or purpose of the property. 

There are six categories of objects: 

a. Simple Object 

A simple object contains only single-valued, nonobject properties. 

b. Composite Object 

A composite object contains one or more nonobject multivalued 

properties. 

c. Compound Object 

A compound object contains at least one object property. 

d. Association Object 

An association object is an object that relates two or more objects 
together and stores data that is peculiar to their relationship. 

e. Hybrid Object 

Hybrid objects are combinations of objects of other types. Most 
frequently, hybrid objects involve the combination of a compound and a composite object 
in which the object property occurs in a composite group. 






f Generalization and Subtype Objects 

Generalization and subtype objects are used to model generalization 
hierarchies. The generalization objects contain the generic description and indicate all 
possible alternatives for the object property, while the subtype objects inherit the 
properties from the generalization objects. 

The process for developing semantic objects can be done in either a top-down or 
bottom-up fashion. With the bottom-up approach, developers examine the application 
interface (primarily, reports and screen displays) and work backwards to derive the object 
structure. With the top-down design, the developer starts with the general idea of the 
goals of the application, involves the user in the development team and tries to determine, 
based on the nature of the objects and the application goals, what the properties are and 
how they are going to be stored in the database. The top-down approach requires more 
experienced developers and is risky. There is a significant chance that the imagination 
of even skilled database designers will be insufficient and that important properties or 
objects will be left out. 

Probably the best approach is the combination of both the top-down and bottom-up 
design. The best and the recommended way to proceed is to have in mind the 
application's conceptual idea, know the desired goals and the systems functionality, 
involve the user in the development phase and start work having the reports and the user's 
favorite interface "handy". Keep in mind that: "Data Modeling is an Artistic Process" 
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2. Data Dictionary 

A data dictionary or project dictionary as it is sometimes called, is a catalog 
of requirements and specifications for a new information system. (Witten, 1989, p.33 1 ) 
It provides definitions of all the data items in the database. During the definition phase, 
the analysts try to capture and store the data in the system, and find the inputs and 
outputs that the system will generate. These are represented with pictorial models such 
as data flow diagrams, relation diagrams, entities, data stores etc. The data dictionary 
expands this pictorial model and as a system analysis tool, captures the detailed 
requirements for every input, output and data store. The suggested approach for building 
the data dictionary should be in terms of "what" data are handled and not in terms of 
"how " data are presented or formatted. 

3. Process Requirements 

All systems process data to produce information and maintain stored data. These 
requirements should be logically modeled. In order to implement processes as programs, 
a process model is needed. A process model is a picture of the flow of data through the 
system and the processing that must be performed on that data. These processes interact 
or interface with one another. These interactions take the form of data flows between 
processes and is the reason that they are sometimes called data flow models. One of the 
most popular system modeling tools for capturing process requirements is the data flow 
diagrams (DFDs). 

It should be emphasized that data flow diagrams are very different from flow charts, 
in the following ways: 
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• Processes on a DFD can operate in parallel; several processes may be working 
simultaneously. This is a key advantage over flowcharts, which tend to show 
only sequences of processes 

• DFDs show the flow of data through a system unlike flowcharts that show 
steps in an algorithm 

• DFDs can show processes that have dramatically different timing while 
flowcharts can't 

The following describes the basic components of a dataflow diagram. 

a. Internal or External Entity 

Every system has a boundary. This boundary is defined by the internal 
or external entities which provide the net input to the system and receive the net output 
from the system. The entities sometimes are called sources or destinations depending on 
whether they are inputs to the system or outputs from the system. Names and titles can 
be used to describe the label of the entities. Entities never interact directly with data 
stores, and relationships between entities are not modeled. 

b. Process 

The emphasis on any DFD is given to the processes, sometimes called 
activities. Processes transform inputs into outputs and transform the structure of data into 
information contained in the data. The logic or the procedure that a process uses to 
complete its task is not shown. Processes are titled by using verb-clause form. 
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a Data Store 



Data stores, as the name implies, shows the logical storage of the 
information. Data flow from a data store represents the "usage" of data. This is the place 
where the data are stored after a process, or from where they are retrieved to be 
processed. 

<L Data Flow 

The data flows represent inputs or outputs that move from or to processes 
and from or to data stores. They are titled by a noun-clause form. Data transferred 
together must be shown as a single data flow no matter how many documents are 
physically involved. 

There are two different but equivalent symbol sets for DFDs; the Gane-Sarson 
symbols and the DeMacro-Yourdon set. The use of these sets is based on which one the 
user feels more comfortable with. Figure 4, introduces the two different sets of models 
and shows how the entities, the data flows, the processes and the data stores are 
represented in each of the models. 
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e, Leveling of DFDs 

When studying, analyzing and designing a system, it is good to have a 
generic pictorial outline of what the system does or will do when it is implemented. This 
pictorial outline which is called "Decomposition Diagram", also called "hierarchy chart", 
shows the top-down functional decomposition or structure of a system. Decomposition 
diagrams also provide an outline for drawing the DFDs. Only the processes are presented 
on decomposition diagrams and they are connected to form a treelike structure. Process 
names conform with the ones that are referred to in the DFDs. The top process is called 
the root; it is exploded or factored out to subsystems, functions or tasks. It defines the 
scope and boundary of the system to be developed. 

D. DATABASE DESIGN 

The goal of the design phase is to develop a blueprint of all five components, 
shown in figure 2, of the information system. For the data component, the structure of 
the database is developed. To accomplish that, the development team translates the user 
data model into specific data structures. For the process component, the process model 
is transformed into an application design. 

1. Logical Database Design 

After the semantic objects are developed, the next step is to transform these 
objects into a relational design. The resulting relations are then normalized. This is a 
very important part of the design because we need to be sure that the objects’ relations 
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will not suffer from any update anomalies. The process of normalization is discussed in 
the following section. 

a. Normalization 

Normalization is the process of forming well-designed relations by 
grouping attributes together. This process examines the relations to test if they are in one 
of the predefined normal forms. The normalization process ensures data is stored in a 
manner that minimizes data redundancy and update anomalies while maintaining data 
integrity. The normal forms are shown in figure 5. 
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As indicated in figure 5, each of the higher normal forms contains the lower ones. 
This means, for example, that a relation that is in the third normal form is also in both 
first and second normal forms. Therefore the steps in the normalization process are 
progressive and one normal form follows another. In each step only certain anomalies 
are eliminated. It is mandatory for relational database designers to satisfy the 
requirements of all the normal forms to ensure that all anomalies have been eliminated. 

(1) First Normal Form (INF) 

A relation is in the first normal form if it has no repeating groups. 
That means that all the attributes in the relation are atomic. Since this is the definition 
of the relation, we can safely say that every normalized relation is in the first normal 
form. 

(2) Second Normal Form (2NF) 

A relation is in the second normal form if it is in first normal form 
and all non-key attributes are dependent on all the attributes of the key. If the key is a 
single attribute then the relation is automatically in the second normal form. If the key 
is a set of attributes then all the non-key attributes must be fully functionally dependent 
on that key. 



21 



(3) Third Normal Form (3NF) 

A relation is in the third normal form if it is in second normal form 
and it has no transitive dependencies. A transitive dependency occur if A— >B, B-*C, then 
A — >C. 

(4) Boyce-Codd Normal Form (BCNF) 

A relation is in Boyce-Codd normal form if it is in third normal form 
and every determinant is a candidate key; any attribute that functionally determines any 
other attribute is a candidate key. 

(5) Fourth Normal Form (4NF) 

A relation is in the fourth normal form if it is in Boyce-Codd normal 
form and the multivalued dependencies are eliminated. This case exists when there are 
more than two attributes in a relation, two of them are multivalued, and their values 
depend only on a third attribute. 

(6) Fifth Normal Form (5NF) 

A relation is in the fifth normal form if it is in forth normal form 
and does not have a joint dependency. 

(7) Domain / Key Normal Form (DK/NF) 

A relation is in Domain/Key normal form if every constraint of the 
relation is a logical consequence of the definition of keys and domains. A domain is a 
description of the allowed values of an attribute. Fourth, fifth and the domain/key normal 
forms have little practical usefulness and are usually ignored in practice. 
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2. Application Design 

The design phase includes the design of both the database and the application. 
An application is the collection of menus, forms, reports, and programs that provide a 
means of update, display, and control the objects of the data model. During the 
application design, the specific structure of forms, reports, menus, and query facilities are 
defined. Also, the logic of transaction programs that will be written for the system is 
developed. The application design will be discussed further in chapter IV. 

E. DATABASE IMPLEMENTATION 

The system's implementation is the set of activities following the logical design, and 
consists of the production of a working system that accepts input from the user, processes 
data and produces the desired outputs. One very important task during the development 
of a software application is the development of the user's manual. 

F. OTHER CONSIDERATIONS 

Important issues such as testing, security, training, conversion, maintenance, and 
future upgrades will be considered and discussed later in chapter VI. 

Testing has been defined as "the fiendish and relentless process of executing all or 
part of a system with the intent of causing it to exhibit a defect" (Page-Jones, 1988, p. 
358). The testing phase has traditionally involved first the testing of separate parts of the 
system and then the testing of the system as a whole. The whole system is then turned 
over for acceptance testing (quality assurance). Acceptance testing is carried out by the 
user, the user's representatives, the analysts, the standards group, external system auditors. 
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or any combination thereof. Structured techniques emphasize the interweaving of the 
testing phase as much as possible with the implementation phase so that the system 
quality is "built in" rather than "added in" after the fact. The development of test cases 
and a test plan can begin at the end of analysis and be carried out during the design phase 
itself. This will ensure that testing is ready to begin as soon as the implementation phase 
commences. 

1. Testing Techniques 

All testing involves the following six steps: 

a. Select what is to be measured by the test. The goal of the test must be 
determined. Are the requirements to be tested for completeness? Is the code being tested 
for reliability? Is the design being tested for cohesion? 

b. Decide how whatever is being tested is to be tested. A decision of how to test 
for quality must be made. A wide variety of approaches are available, including 
inspection, proofs, black box and white box testing, and automated methods. The tester 
must decide what kind of test is to be used to measure the desired quality. 

c. Develop the test cases. Once the actual test has been decided the actual test 
cases must be created. A test case is simply a set of data or situations that will be used 
to exercise the unit being tested. 

d. Determine the correct or expected results from the test and create the test oracle. 
It is very important for the tester to know what the correct result should look like, and 
determine the "test oracle" which is the predicted results for a set of test cases. 

e. Execute the test cases. In this step the tester has to carry out all the tests. 
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f. Compare the results of the tests to the test oracle. A very careful comparison 
between the actual results of the test and the test oracle should be done in this step. Any 
discrepancy between the predicted results and the actual results signals an error. The 
source of the error must be tracked down. In most cases the error is in the system that 
is being tested. However, in some cases, the error may be in the testing process or in the 
test oracle. 

In order to understand the testing techniques more clearly let's take the sample 
system of figure 6, and see in what ways this system can be tested. Figure 6 shows a 
sample modular hierarchy of a hypothetical system. Modules A,B,C,D,E,F and G 
represent parts of the developed units/code to be tested. 




Figure 6: Sample Modular Hierarchy 



a. Traditional Approach to Testing 

Figure 7 shows the traditional testing technique which requires testing 
every module after its completion phase, integrating the whole system, and testing the 
complete system at once. Following the traditional testing technique the tester may 
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experience difficulties at the integration point where he has to test the complete system 
and where most of the problems are surfaced. 




b. Top-down Testing Strategy 

In this case the testing procedure is driven by the system modular 
hierarchy and follows the top down design. Figure 8 shows the top-down testing strategy 
which is characterized by relatively early integration, no need for module drivers (modules 
that are not fully implemented), low work parallelism at the beginning, and difficulty in 
testing particular paths, and planning and controlling the sequence of tests. 
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Figure 8:Top-down Testing 
a Bottom-up Testing Strategy 



Figure 9 shows the bottom-up testing strategy in which every individual 
module is tested starting from the bottom and working backwards to the top. This 
technique is characterized by late integration, need for module drivers, medium work 
parallelism at the beginning, ability to test particular paths easily, and difficulty to plan 
and control the sequence of tests. 
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(L Sandwich Testing Strategy 

Figure 10 shows the sandwich testing strategy which is a combination of 
both top-down and bottom-up testing strategies, and ensures that all the modules have 
been implemented as soon as the "Test A, B, C, D, E, F, G" modules have been tested. 
This technique is characterized by early integration, medium work parallelism at the 
beginning, medium ability to test particular paths, and difficulty to plan and control the 
sequence of tests. 




2. Security 

Database security is important because databases are so critical to an 
organization. Even with an efficient operating system, data is at risk if a reliable database 
system is not used. Operating systems usually protect data at the file level. Databases 
however need protection at different levels such as table or relation, row or tuple, or even 
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element. In addition, different discretionary security policies are often desired for 
database systems that restrict access to specific data through specific operations, such as 
insert, update, retrieve and delete. Such controls are not available in operating systems. 

There are seven conceptual requirements for database security. These are 
authentication, access control, availability, physical integrity, logical integrity, element 
integrity and audit trail. There is a certain amount of dependence between these seven 
aspects, since a failure in one area may expose the database to increased vulnerability 
from the remaining areas. 

Authentication is the requirement to positively identify every user of the database. 
This may be achieved through the use of information known only to a particular user, 
(e.g. password), the use of some physical item, (e.g. a key or pass card), or reference 
to some physical aspect of the user (e.g. fingerprints, voice pattern). 

A ccess control defines the who and the what of allowed activities on the system's 
data. The who describes which subjects have access to which objects. The what defines 
the operations (e.g. read, write, etc.), allowed on each object. Figure 11 shows an 
example of an access control list for three users and three relations. This sample access 
control list permits user "X" to access relation "A" to insert, read, update and delete data. 

A vailability means that authorized users should not experience denial of service. 

Physical security involves protecting the media which stores the database from 
damage This may include measures to protect the physical media from natural disasters, 
fire, and accidental or intentional abuse. 
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Figure 11: Access Control List Example 

Logical integrity involves protecting information about the logical structure (schema) 
of the database, which in many occasions is stored separately from the base data. 
Element integrity is concerned with the accuracy and correctness of the data in each data 
element. 

A udit trails answer the who, what and when about access to data in the database. 
It is a permanent record of who has accessed what elements of the database, what actions 
were performed upon them, and when the action took place. 

3. Conversion 

The conversion phase is probably the most important phase of the system 
implementation from a managerial perspective. This is the time that users and system 
development personnel have to work closely together. Human nature is to resist any kind 
of changes, especially if they are not ready or prepared for that change. Factors such as 
organizational structure, human resources, and political and cultural climate all come into 
play. Management sometimes has to restructure the organization chart when a 
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computerized system is implemented into the organization environment. Human resources 
are often reallocated to and from the new system so the principle of "the right man in the 
right position" will be guaranteed. Conflicts among users and workers who don't believe 
in automation should be expected. Furthermore, some employees view training programs 
as a threat because they believe that evaluations made at the end of the training will be 
used against them. 

a. Strategies 

There are four strategies that can be used to implement a system. 

They are: Parallel Conversion, Direct Conversion, Phased Conversion, and Pilot 
Conversion. 

(1) Parallel Conversion 

Figure 12 shows the parallel conversion technique which is widely used. It 
consists of operating both the old and the new system at the same time, until management 
is satisfied that the new system is working efficiently. At this point the old system is 
discontinued. This technique eliminates the risk involved with implementing a new 
system, but requires a lot of manpower to maintain both systems in operation. 
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Figure 12: Parallel Conversion 



(2) Direct Conversion 

Figure 13 shows the direct conversion which is characterized by 
shutting down the old system at the end of one workday and starting up the new system 
the next workday. This technique can be extremely risky, but it is gaining in popularity 
over the parallel conversion strategy for the following reasons: 

• By using the parallel approach, the need for manpower is greater. 
Furthermore, by continuing with the old system, it may cause some users not 
to make a genuine effort to support the new system 

• With thorough testing of the system and training of the personnel, the new 
system should operate at acceptable levels 

• In many cases the risk of failure of the new system may be acceptable 
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Figure 13: Direct Conversion 



(3) Phased Conversion 

Figure 14 shows the phased conversion technique through which the 
old system is phased out and the new system is gradually phased in. This approach has 
many of the same problems that parallel conversion has, primarily because both systems 
operate simultaneously. Furthermore, the outputs of the two systems have to be combined 
to obtain a total picture. Finally, by shifting to the new system, no backup of the old one 
exists, and if the new system fails then the only way to retrieve lost information is by 
reverting completely to the old system. The big advantage is that the shift from the old 
system to the new one is quite smooth. As the user gradually becomes familiar with the 
new system while continuously using it, he starts seeing the advantages of the new 
system. This is a key factor in minimizing user resistance. 
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Figure 14: Phased Conversion 



(4) Pilot Conversion 

Figure 15 shows the pilot conversion technique. Pilot conversion 
consists of implementing the new system in a selected portion of its ultimate site. If the 
system operates efficiently on this selected portion, it is then fully implemented at the 
entire site. Within the pilot area, the system can be implemented in any of the previously 
discussed methods. The pilot approach avoids many of the problems that the other 
alternatives have. One drawback however, is that it does not test whether the system will 
operate satisfactorily under the increased volume of full implementation. 
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Figure 15: Pilot Conversion 
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HL REQUIREMENTS ANALYSIS FOR SPAS 



In this chapter we will discuss both the data and the process requirements for the 
SPAS application. We will create the data model and the corresponding data flow 
diagrams that represent the data flow that create, update and display the objects of the 
data model. 

A. DATA REQUIREMENTS 

Data requirements are captured in the form of semantic objects and associated data 
dictionary. This application consists of seventeen (17) semantic objects that are shown 
in Appendix A. In this diagram objects and object properties are indicated in upper case, 
attributes in mixed case, and identifiers are underlined. 

1. SHIP 

A ship has a name, belongs to a class, is commanded by a Commanding 
Officer, helped by an Executive Officer and belongs to a higher command. The ship 
internally is organized into DEPARTMENTS. 

2. DEPARTMENT 

A department has a name, is controlled by the department head who is an 
officer, and has an office and a phone number. It belongs to the SHIP and contains and 
controls one or more DIVISIONS. 
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3. DIVISION 



Similar to a department, a division has a name, is controlled by the division 
officer, and has an office and phone number. Every division has one or more PERSONS 
and belongs to a DEPARTMENT. 

4. PORT DUTY STATION 

A port duty station that the PERSON could be assigned to while in port has 
a name, a location and a phone number. 

5. PERSON 

The persons onboard the ship work for a DIVISION. Every person has a 
unique identification number, a first and last name, a military rank and rate, owns a 
current position after being reassigned from his previous one on a certain date, has a 
specialty, and should belong to three different division systems in order to be able to 
complete his individual tasks depending on the general ship’s situation. These systems 
are the one third crew division system that applies when the ship is underway with three 
watch shifts, the one half that applies when the ship is on two shifts and a session 
division system that applies every morning while in port for the XO's daily report. Every 
person has a date of birth, an address, has to provide his nearest police station address and 
phone number in case of emergency, has a religion , hobbies, background education and 
may speak one or more foreign languages. As soon as he embarks he is assigned a 
berthing place, some SPECIAL DUTIES, a PORT DUTY STA TION, an ABANDON 
SHIP STA TION in case of an abandon drill or a real situation and one or more SPECIAL 
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STA TION when the ship is mooring, anchoring towing or being towed. At any time, a 
person has the right to take LEA VE or to ask for a SPECIAL REQUEST. The command 
is also interested in other personal data, like the person's DEPENDENTS , his FITNESS 
condition, his PROMOTION s and some work experience data, such as being qualified as 
an air controller and his current qualification category. Any time he performs AIR 
CONTROL CHECKS it is recorded and the ship is required to report it every month. 
Furthermore, all personnel are subject to periodic ON THE JOB TRAINING 
EVALUATIONS. Finally, a person undertakes TRAINING and is subject to 
DISCIPLINARY actions. 

6. SPECIAL STATION 

A special station that the PERSON could be assigned to has a type and a title. 
The person has a duty and has to carry some equipment and there is a location where all 
the persons have to be gathered. 

7. SPECIAL DUTY 

Similar to the station, a special duty that the PERSON could be assigned to 
has a type, a title and each person has some instructions. They have to carry some 
equipment and/or some armament depending on the mission and there is a location where 
they have to be gathered. 

8. DEPENDENT 

The crewmember's ( PERSON jdependent has a name, lives at an address, and 
has a phone number. There is a possibility that the crewmember has other dependents. 
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9. DISCIPLINARY 



Any PERSON onboard could commit an " illegal " action and be disciplined. 
That offense reported by an officer, has a number, a name and a date when it was 
committed. The person has the right to give his apology, while the command has to 
decide his punishment, the date that punishment starts, and the date that it ends. 

10. PROMOTION 

Normally, after a certain period of time the PERSONS onboard, commissioned 
officers and petty officers get promoted. The command needs to know the promotion 
date, the command issued the order for the promotion and the date of the issued order. 

11. FITNESS EVALUATION 

Once a year, all PERSONS have to be evaluated for their fitness condition. 
The fitness evaluation has a reference period, a start date, an end date, a pass or fail 
evaluation grade and any possible comments. 

12. ON THE JOB TRAINING (OJT) EVALUATION 

PERSONS periodically are evaluated on their job in order to be qualified or 
to refresh their technical skills and knowledge. The OJT evaluation is performed by the 
person's department head, has a start date, an end date, the resulting grade, any possible 
comments and the station that the person is qualified for. 

13. TRAINING 

The training of crewmembers is a continual activity. There are required 
schools that crewmembers have to attend in order to get promoted and there are schools 
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whose attendance is on a volunteer basis. The ship's command needs to know what 
school each of the PERSONS have attended, the date, the degree or the diploma, the grade 
that the person obtained, his order of success among the other participants and any 
possible comments. 

14. AIR CONTROL CHECK 

PERSONs that are qualified as air controllers and are capable of performing 
tactical control on fixed wings or helicopters have to record each control check they 
perform, and the ship's command has to submit a consolidated report every month to the 
Tactical Training Center. The air control check has a date and a time that the control was 
performed, the type of the aircraft, the type of the control and its duration and possible 
comments. 

15. LEAVE 

By law, each person is entitled to 30 days normal leave every year. However, 
depending on the situation and the CO's decision, he could get additional days off. This 
special leave could be for personal/private reasons or for educational purposes. For 
example, special leave could be granted while the person is studying at a university and 
has to take exams, or, it could be given as a reward. The PERSON'S leave is described 
by its type, has a date starts, a date ends, the number of days in leave, destination, as well 
as any possible comments. 
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A crewmember serving onboard the ship can submit requests, mostly 
concerning administrative issues. He can ask to report something personal to the CO or 
the XO, or ask to be heard by the higher commander or even by the Admiral of the Fleet. 
PERSON'S request has to be recorded and has a date, a type, a description, the CO's 
decision and any possible comments. 

17. ABANDON SHIP STATION 

On the " ABANDON SHIP " order, everyone has to be at his abandon ship 
station. This is any of the life rescue facilities of the ship either a rescue boat or a 
floating raft. The abandon ship station has a number, a location, a type and a capacity. 
All of the PERSONS are assigned to an abandon ship station. 

B. DATA DICTIONARY 

The SPAS application data dictionary is shown in Appendix B. It describes each 
object, its properties, the data type, width, and definition of each property. 

C. PROCESS REQUIREMENTS 

In this application, the decomposition diagram and the data flow diagrams that 
describe the system's functionality are shown in Appendix C. The system has four levels. 
The zero level is the overall system picture named Shipboard Personnel Administration 
System ( SPAS ). It is factored into three different subsystems titled Personnel 
Subsystem, Request Subsystem and Report and Query Subsystem. 
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a. Personnel Subsystem 

This subsystem has five processes: process crewmember data, process 
dependent data, process disciplinary data, process evaluation data and maintain person 
data. The process evaluation data consists of two subprocesses: on the job training 
evaluation data and fitness evaluation data. The maintain person data process consists of 
five subprocesses to update the air control, crewmember, dependent, disciplinary and 
evaluation data. All these subprocesses have add, modify and delete mechanisms. Of 
special interest is the process crewmember data process through which all of a person's 
data is entered into the system as well as his assignment to special duties and special 
stations. 

b. Request Subsystem 

The request subsystem has only two processes to process any kind of 
special request or leave request. 

a Report and Query Subsystem 

This subsystem produces predefined reports either for internal or external 
use. The answer specified queries process is considered a utility for the production of 
internal reports to support the ship's command with any kind of information relative to 
a person. The produce internal reports process is split into the following subprocesses: 
produce person's information card, produce person's information book, produce fitness 
evaluation report, produce a division system report and produce a special duty report. 
The produce external reports process produces the air controllers' monthly report, the 
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officers' special report, the officers' monthly report, the sailors' monthly report and the 
sailors punishment monthly report. 



D. HARDWARE REQUIREMENTS 

The system being developed will be implemented on an IBM compatible PC 
platform found on many Hellenic Navy ships. The minimum hardware configuration is 
a 386 SX (16 bit architecture) processor running at 25 Mhz, with 2 Mb of RAM and 65 
Mb of hard drive. 

The following chapter will describe the logical database and application design for 
SPAS. 
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IV. LOGICAL DATABASE AND APPLICATION DESIGN FOR SPAS 



In this chapter we will discuss the logical database and application design for SPAS. 
In logical database design, the object model developed in the previous chapter is 
transformed into a relational schema, in preparation for implementation using a specific 
DBMS. In application design, the data flow diagrams are used as a basis for developing 
the menus, forms, and reports for SPAS. 

A. LOGICAL DATABASE DESIGN 

The seventeen semantic objects describing the user's environment are transformed 
into nineteen relations. Relationships are represented using foreign keys and are also 
shown explicitly on the relational diagram. In this diagram, shown in Appendix D, 
primary keys are underlined and foreign keys are indicated with the superscript FK . 
Relations of Appendix D, their attributes, and relationships are discussed in the following 
sections. 

1. Ship Relation 

This relation contains information about a ship. It is derived from SHIP 
object. Its primary key is Hull Number. Other attributes are Ship's Name, Ship's Class, 
Commanding Officer's Name, Executive Officer's Name, and Higher Command. It has 
a l:M mandatory relationship to Department relation. 
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2. Department Relation 

This relation contains information about a department. It is derived from 
DEPARTMENT object. Its primary key is Department Name. Other attributes are 
Department Head, Office Location, Phone Number and Hull # (foreign key). It has a M:1 
and a 1:M mandatory relationships to Ship and Division relations respectively. 

3. Division Relation 

This relation contains information about a division. It is derived from 
DIVISION object. Its primary key is Division Name. Other attributes are Division 
Officer Name, Office Location, Phone Number and Department Name (foreign key). It 
has a M:1 and a 1:M mandatory relationships to Division and Person relations 
respectively. 

4. Person Relation 

This relation contains information about a person. It is derived from PERSON 
object. Its primary key is Personal Identification Number. Other attributes are Last 
Name, First Name, Rank, Rate, Current Position, Previous Position, Date of Change, 
Specialty, Date of Birth, Address, Nearest Police Station and Phone Number, One Third 
Crew Division System Number, One Half Crew Division System Number, Session 
Number, Berthing, Religion, Education, Foreign Languages, Hobbies, Air Control 
Category, Instructor Air Controller, Division Name (foreign key). Port Duty Station Name 
(foreign key), and Abandon Ship Station Number (foreign key). It has a M: 1 mandatory 
relationship to Port Duty Station, Division, and Abandon Ship Station relations, a 1:1 



45 



optional relationship to Fitness Evaluation, Dependent and Air Control Check, a 1:M 
mandatory relationship to Promotion, Person-Special Duty, and Person-Special Station 
relations, a 1:M optional relationship to Disciplinary, Training, Request, Leave, and On 
the Job Training Evaluation relations. 

5. Dependent Relation 

This relation contains information about a person's dependent. It is derived 
from DEPENDENT object. Its primary key is Dependent's Name and Personal 
Identification Number. Other attributes are Address, Phone Number and Other Dependent 
Names. It has a 1:1 mandatory relationship to Person relation. 

6. Fitness Evaluation Relation 

This relation contains information about a person's fitness evaluation. It is 
derived from FITNESS EVALUATION object. Its primary key is Reference Period for 
Fitness Evaluation and Personal Identification Number. Other attributes are Start Date, 
End Date, Grade, and Comment. It has a 1:1 mandatory relationship to Person relation. 

7. On the Job Training Evaluation Relation 

This relation contains information about a person's OJT evaluation. It is 
derived from OJT EVALUATION object. Its primary key is Start Date for the OJT 
Evaluation and Personal Identification Number. Other attributes are End Date, Grade, 
Comments, Station duty of Qualification, and Officer Performed the Qualification. It has 
a M:1 mandatory relationship to Person relation. 
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8. Disciplinary Relation 

This relation contains information about a person's Disciplinary actions. It is 
derived from DISCIPLINARY object. Its primary key is Offence Number and Personal 
Identification Number. Other attributes are Offence Name, Offence Date, Apology, 
Punishment, Start Date, End Date, and Reporting Officer. It has a M:1 mandatory 
relationship to Person relation. 

9. Training Relation 

This relation contains information about a person's Training. It is derived from 
TRAINING object. Its primary key is School Name and Personal Identification Number. 
Other attributes are Date, Degree/Diploma, Number of Participants, Grade, Order among 
Participants, and Comments. It has a M:1 mandatory relationship to Person relation. 

10. Promotion Relation 

This relation contains information about a person's Promotion. It is derived 
from PROMOTION object. Its primary key is Promotion Date and Personal Identification 
Number. Other attributes are Command Issued the Order, and Date of Issued Order. It 
has a M: 1 mandatory relationship to Person relation. 

11. Port Duty Station Relation 

This relation contains information about a port duty station. It is derived from 
PORT DUTY STATION object. Its primary key is Port Duty Station Name. Other 
attributes are Station Location and Phone Number. It has a 1 :M mandatory relationship 
to Person relation. 
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12. Air Control Check Relation 



This relation contains information about air control checks. It is derived from 
AIR CONTROL CHECK object. Its primary key is Date, Time, and Type of Aircraft. 
Other attributes are Type of Control, Duration, Comments and Personal Identification 
Number (foreign key). It has a 1:M mandatory relationship to Person relation. 

13. Request Relation 

This relation contains information about a person's requests. It is derived from 
REQUEST object. Its primary key is Date, Personal Identification Number, and Type of 
Request. Other attributes are Description, CO's Decision, and Comments. It has a M:1 
mandatory relationship to Person relation. 

14. Leave Relation 

This relation contains information about a person's leave. It is derived from 
LEAVE object. Its primary key is Date Starts and Personal Identification Number. Other 
attributes are Date Ends, Type of Leave, Number of Days on leave. Destination, and 
Comments. It has a M:1 mandatory relationship to Person relation. 

15. Abandon Ship Station Relation 

This relation contains information about an abandon ship station. It is derived 
from ABANDON SHIP STATION object. Its primary key is Abandon Ship Station 
Number. Other attributes are Location, Type of Rescue Vessel, and Capacity. It has a 
1:M mandatory relationship to Person relation. 
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16. Special Station Relation 

This relation contains information about a special ship station. It is derived 
from SPECIAL STATION object. Its primary key is Special Station Type and Special 
Station Title. Other attributes are Duty, Equipments, and Gathering Position/Location. 
It has a 1 :M mandatory relationship to Person-Special Station relation. 

17. Person-Special Station Relation 

This relation contains information about a person and his special ship station. 
It is derived from PERSON and SPECIAL STATION objects. It is an intersection 
relation that breaks the many to many relationships between person and special station 
into two T.M relationships. Its primary key is Personal Identification Number, Special 
Station Type, and Special Station Title. It has a M:1 mandatory relationship to Person 
and Special Station relations. 

18. Special Duty Relation 

This relation contains information about a special ship duty. It is derived from 
SPECIAL DUTY object. Its primary key is Special Duty Type and Special Duty Title. 
Other attributes are Duty Instruction, Equipments/Guns and Ammunition, and Gathering 
Position. It has a 1 :M mandatory relationship to Person-Special Duty relation. 

19. Person-Special Duty Relation 

This relation contains information about a person and his special duty. It is 
derived from PERSON and SPECIAL DUTY objects. It is an intersection relation that 
breaks the many to many relationships between person and special duty into two 1:M 
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relationships. Its primary key is Personal Identification Number, Special Duty Type, and 
Special Duty Title. It has a M:1 mandatoiy relationship to Person and Special Duty 
relations. 

B. APPLICATION DESIGN 

In application design, the data flow diagrams developed in the requirements phase 
are used as the basis for designing the system's menus, forms, and reports. The following 
section provides a brief explanation of each. 

1. Menus 

SPAS is a menu-driven application. The reason for using menus is because 
they are self explanatory and are therefore easy to use. The menu structure of SPAS 
follows closely the decomposition diagram developed during process requirements. SPAS 
menus are shown in Appendix E. 

2. Forms 

Forms are the user's primary interface with the database. They are used for 
entering, modifying, and displaying data retrieved from the database. Special care was 
paid in designing the forms for SPAS. Every effort was made in designing them to be 
natural, easy to use, and be less prone to errors. SPAS forms are shown in Appendix F. 

3. Reports 

Reports are the main output that the system generates for distribution to a 
variety of users. Reports can be sent to the screen, to a file, or to the printer. Similar 
to designing forms special care was paid in designing the reports for SPAS. Every effort 



50 



was made in designing them to be natural, logical, close to the format that is currently in 
use, and less prone to misinterpretation. SPAS reports are shown in Appendix G. 
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V. IMPLEMENTATION FOR SPAS 



In this chapter we will discuss the implementation of the SPAS application and the 
construction of the database, as well as the installation of both the database and the SPAS 
application. The Paradox database management system for DOS is introduced and used 
as the DBMS of choise for SPAS implementation. 

Paradox is a fast, full-featured, and easy to use relational database program designed 
to meet data management needs. Paradox can be used by computer users with all levels 
of experience from beginning database users to advanced developers. Paradox can be 
used either on a single computer (standalone) or on a Local Area Network (LAN). 

To use Paradox 4.0 on a standalone computer, you will need at a minimum: 

• a 100% IBM compatible, protected mode capable 80286 or higher personal 
computer with a hard disk and a floppy drive 

• 2MB extended memory 

• DOS 3.0 or higher, or OS/2 2.0 

• compatible MDA, MCA, CGA, EGA, VGA, 8514, 3270, ATT, TANDY 
T1000, or Hercules monitor with adapter 

• 5MB of free hard disk space to install Paradox without the optional software 
and 0.5MB for the optional software 

• free hard disk space approximately three times the size of your largest table, 
to process complex queries 
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The user interface for Paradox supports multiple windows, pull-down menus, speed 
bars, dialog boxes, and other graphical user interface components. Paradox provides 
limited mouse support. For instance, you can't change directories when loading tables by 
pointing and clicking at a directory tree with the mouse; you have to type your path 
manually. Paradox's Query By Example (QBE) capability is one of the product's strong 
features. Complex queries can be nm against single or joined tables, and query images 
can be saved for later use. A variety of exact and inexact queries can be performed, and 
there is support for wildcards, data ranges, pattern searches, and logical conditions. 
Phonetic searches can be done with Paradox's "Like" operator. Database administration 
is handled through Paradox's well-designed user interface which puts all the commands 
the user needs on easy-to-use menus and provides shortcut keys for many of the choices. 

A. DATA IMPLEMENTATION 

In data implementation, the relations and their attributes developed during logical 
database design are transformed into tables and data fields, respectively. Table structures 
are created in Paradox by choosing Create from the menu, and specifying a name for the 
new table in the -dialog box. The structure of the new empty table, which matches the 
corresponding relation developed during the design phase, is then specified. For each 
field of the table, its name, field type, and whether it is a key field are entered. Brief 
descriptions of the field type choices are displayed on the new table creation window to 
assist the users in creating the new table. The data types supported by Paradox and their 
abbreviations are: A for alphanumeric fields up to 255 characters in length, M for a memo 
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up to 240 characters in table view, N for numbers, $ for currency amounts, and D for 
dates. Once the definition of a table is completed, a user can enter values in the table 
directly or through a form. 

B. APPLICATION IMPLEMENTATION 

A Paradox application is a series of instructions to Paradox that makes it perform 
the set of tasks needed to do a specific job. These instructions link menus, forms, 
queries, and reports into a comprehensive system. In this section we will discuss Paradox 
query module, form and report generator, and application workshop. 

Query module lets the user select, combine, manipulate, and retrieve data in tables. 
To perform a query, a query form has to be filled out first. This form is related to the 
table that contains the data. The Ask command on the main menu displays the Query 
form. Several forms can be linked together, and the designer is able to retrieve all the 
information he needs into a single table. He can also set conditions to be satisfied when 
the query is performed. Setting conditions is a simple action of making the Queiy form 
look like an example of the records he likes to retrieve. This is called Query by Example. 
The retrieved data are stored in a temporary table named Answer. 

Paradox has a form/report generator that allows the programmer to design custom 
forms and reports. Forms are used to input data one record at a time. A form can have 
wrapped fields that show the information of a single field on two or more lines. The 
information in a table image is always arranged in rows and columns, whereas the 
information on a form can be arranged in a free format. Data fields are highlighted in 
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different colors for easy recognition with a cursor that tabs from one logical data field to 
the next. Forms are created by choosing Form, Design from the menu. Paradox default 
is a standard tabular formatted form. The designer has the option to design a custom free 
format form. Appendix F shows SPAS data input forms. 

Reports are produced to display the requested information from the database. Each 
table can have up to 15 reports defined on it. Each report can have up to 2000 characters 
per line. Reports are created by choosing Report, Design from the menu. Paradox default 
is a standard column report. The designer has the option to design a custom free format 
report. Appendix G shows SPAS customized reports. 

Paradox application workshop helps the programmer to create Paradox Applications 
easily. The application menus are created through the application workshop. Building 
the menus and defining what each command menu does is accomplished through the 
application workshop. The application workshop creates and manages the components 
of the application. Another way to create these components is by using PAL 
(Programming Application Language) scripts which is more complex and designed for 
more advanced applications and experienced programmers. For the development of SPAS 
application, a combination of both the application workshop and PAL was used. 

Appendix H shows the programming code generated by Paradox while building the 
SPAS application Part one of the Appendix is the "Menu Structure" that shows the 
hierarchy of the SPAS application menu structure. Part two is the cross-reference table 
of "Action Objects & Paradox Objects in Use" that explains in each session what tables 
are declared, what functions (insert, edit, delete) are performed, and if the specific session 
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is password protected. Part three is the action table menu that describes in detail how 
each of the actions is performed. 

Appendix I provides procedures for installing and operating SPAS. 

The next chapter discusses other issues that need to be taken into consideration 
before SPAS can be fully operational. 
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VI. OTHER ISSUES 



In this chapter important issues concerning the development of the "SPAS" 
application such as testing, security, training, conversion, maintenance, and future 
upgrades will be discussed. 

A. TESTING 

As mentioned in chapter n, testing is critical for the development of the SPAS 
application. Database management system testing abilities as well SPAS testing strategy 
will be discussed at this point. 

1. Paradox Testing 

Paradox is designed to allow the developer to conduct testing through the use 
of environments. In the "Workshop" environment, after each programming session is 
implemented the user is able to test the specific module and be assured that it is fully 
functional without any procedural errors. When the application is finished, it can and 
must be tested as a whole. Paradox has that feature built in the application workshop 
under "Application/Test" which tests the application to ensure that everything after the 
integration works properly. 

2. 'SPAS" Testing Strategy 

As mentioned in the previous paragraph, Paradox lets the developer test the 
application at every procedural step. While building each of the action menus, the 
developer is able to test every action, session, or report, to ensure that everything is 
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working properly, and continue to the next menu for further development. So, in this 
session, access to all of the tables and forms is ensured, all queries are performed, and 
everything is verified to be working properly. This "built in" testing procedure in Paradox 
represents the bottom-up testing strategy that is described in paragraph II.E.2.C. The 
bottom-up testing technique was performed throughout the development of the SPAS 
application and each individual process was tested before proceeding to the next higher 
step in the application's hierarchy. Each subsystem was tested in that way ensuring no 
functional or procedural errors were present. The whole application was then tested as 
a complete and integrated system. 

B. SPAS SECURITY 

Paradox offers a very flexible passwording scheme with table-by-table, 
script-by-script, and option-by-option password protection. Access to a given table can 
be limited on a field-by-field basis. 

SPAS users will have some access control authorities depending on their rank and 
their duties onboard the ship. The command is responsible for assigning these duties and 
for determining each user access control. 

SPAS physical security falls under the navy's policy and procedures that enforce 
rules and activities for the ships' physical security. Moreover, each individual ship 
command has to take proper measures to protect the hardware resources as well as the 
software and the applications. 
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C. TRAINING 



One of the most important aspects of the implementation phase is the training plan 
The training plan is designed to ensure that every user of the system knows the system's 
basic functions and how to perform them. The success of any information system 
depends on the skills of the operators. In the SPAS system, the operators are officers, 
petty officers and sailors, who are familiar with the procedures on the ship, currently run 
the system manually, and who only need to be taught how the new system operates. The 
system itself is designed to be friendly, easy-to-use, and does not require the operator to 
have any advanced interpersonal skills. However, matching basic human characteristics 
and skills with a job's requirements is essential, especially when an automated system is 
to replace a manual one. 

The designer's proposal for the training is to start with the main users of the system 
and train them in the system's environment as well as its functions and operations. The 
main users of the system are defined as personnel working in the ship's administration 
office. They are led by the administration officer whose team normally consists of two 
petty officers and three or four sailors. As soon as every ship has a trained core of 
system users, training for the rest of the personnel can be held. 

D. CONVERSION 

The future success of the new system depends on how well and how quickly it is 
accepted by the users. With SPAS application, it is hoped that because the system is 
rather small and the users are already familiar with the environment, proper training will 
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minimize these problems. Another way to minimize implementation problems is to select 
the correct conversion strategy. 

1. SPAS Conversion Strategy 

For the SPAS application conversion strategy, the pilot approach is proposed. 
A parallel conversion within two Hellenic Navy ships as pilot units is desired for the 
following reasons: 

• risk is significantly minimized 

• testing the system on two ships over a period of time will provide sufficient 
information to evaluate the system before complete implementation on all 
ships 

• manpower need is reasonable 

• surfaced problems can be worked out by the personnel of both ships 

• time to shift is predicted to be two months which is a reasonable interval for 
checking monthly reports and for reassigning personnel from/to the ship 

As soon as the system operates sufficiently on the pilot units, a decision for full 
implementation on all ships can be made. 

E. MAINTENANCE 

Once the system passes the acceptance test, it is ready for delivery. Any 
modifications or enhancements after delivery is called maintenance. Attention should be 
paid to the fact that after a few years of operating the original system, maintenance 
becomes extremely tedious, error-prone, and expensive. In this case, management should 
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recognize the problem and do a feasibility study on replacing the old system with a new 



one. 

F. FUTURE ENHANCEMENTS 

The SPAS system design offers a flexible way for future upgrades. Paradox itself 
can be distributed on a network and allow applications to be shared among different users. 
The SPAS system is able to produce all the designed reports in file format. This facility 
allows ships to electronically transfer their reports as soon as all the commands are 
connected to a common network. 
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VIL CONCLUSIONS AND LESSONS LEARNED 



This thesis presented the design, development, partial testing and implementation 
of the Shipboard Personnel Administration System (SPAS) application on a standalone 
computer. The SPAS system will provide the Hellenic Navy ships with an automated 
system to perform their primary administrative functions. SPAS supports this mission by 
keeping track of all the personnel records, maintaining them, producing reports and 
providing the command with ad hoc information. 

No automated system is currently in use and all the administrative activities are 
performed by a manual filing system which is slow, inaccurate and prone to errors. The 
main goal of developing the system is to release manpower to perform other duties, by 
increasing effectiveness, efficiency, and accuracy of personnel management. After SPAS 
implementation, it is hoped that most of the current problems will be eliminated, and 
future enhancements will result in even greater efficiency in performing the personnel 
administration functions. 

System analysis and design tools and techniques were used to develop the system 
by modeling the user data and process requirements. Paradox for DOS was used as the 
database management system for the implementation because it is not only powerful but 
also meets the system's developmental requirements. The window like, pull-down menu 
driven environment is easy to use and quick to leam. The user friendly environment will 
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hopefully eliminate the cultural resistance of the user that will result from the requirement 
to switch from the manual system to an automated one. 

It is hoped this thesis will be the motivator for other efforts to develop new systems, 
and expand or update existing ones in the Hellenic Navy. It is hoped also that the 
developed system would benefit other services of the Hellenic military and give them the 
inspiration to develop their own systems following the pre-designed and tested system 
designed for the Navy and developed in this thesis. 
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APPENDIX A: SEMANTIC OBJECTS 



Hull# 

Ship's Name 
Ship's Class 
CO's Name 
XO's Name 
Higher Command 



DEPARTMENT 



mv 



Department Name 

Department Head 
Office Location 
Phone # 



DIVISION 



mv 



SHIP 



SHIP 



DEPARTMENT 



Division Name 
Division Officer Name 
Office Location 
Phone # 



PERSON 



mv 



DEPARTMENT 



Port Duty Station's Name 

Location 
Phone # 



PERSON 



mv 



DIVISION 



PORT DUTY STATION 



Station-Type 

Title 

Duty 

Equipments 

Gathering Position/Location 




Type of Duty 

Duty Title 
Duty Instructions 
Equipment/Gun+Amo 
Gathering Position 


PERSON 


mv 




PERSON 


mv 



SPECIAL STATION 



SPECIAL DUTY 
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Personal ID # 

Last Name 
First Name 
Rank 

Rate 

Current Position 
Previous Position 
Date of Change 
Specialty 

1/3 Crew Division # 

1/2 Crew Division # 

Session 
Date of Birth 
Address 

Nearest Police Station & Phone # 
Berthing 

Air Control Category 
Instructor Air Controler (Y/N) 
Religion 
Education 

Foreign Languages mv 
Hobbies mv 



TRAINING 



mv 



OJT EVALUATION 



DEPENDENT 



PROMOTION 



DIVISION 



DISCIPLINARY 



mv 



ABANDON SHIP STATION 



SPECIAL STATION 



mv 



SPECIAL DUTIES 



mv 



REQUEST 



mv 



LEAVE 



mv 



AIR CONTROL CHECK 



mv 



FITNESS EVALUATION 



PORT DUTY STATION 



PERSON 
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Offence # 



Dependent's Name 



PE RSON 

Address 
Phone # 

Other Depentent's Name 



DEPENDENT 



PERSON 



Offence Name 
Date of Offence 
Apology 
Punishment 
Start Date 
End Date 
Reporting Officer 



DISCIPLINARY 



Promotion Date 




PERSON 


the Order 
rder 


Command Issuec 
Date of Issued 0 



PROMOTION 



Refer ence Perio d 



PERSON 

Start Date 
End Date 
Grade 
Comments 



FITNESS EVALUATION OJT EVALUATION 



Start Date 



PERSON 



End Date 

Grade 

Comments 

Station Duty of Qualification 
Officer Performed the Qual. 
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School 



PERSON 



mv 



Date 

Degree/Diploma 
No. of Participants 
Grade 

Order of Success among Participants 
Comments 



TRAINING 



Date Sta rts 

Date Ends 

PERSON 

Type of Leave 
No. of Days 
Destination 
Comments 



Date 

Time 

Tvpe of Aircraft 


trol 


Type of Control 
Duration of Con 

Comments 


PERSON 








AIR CONTROL CHECK 


Date 




PERSON 




Tvpe of Request 
Description 
CO’s Decision 
Comments 





LEAVE 



REQUEST 



Abandon Ship Station # 
Location 

Type of Rescue Vessel 
Capacity 



PERSON 



ABANDON SHIP STATION 
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APPENDIX B: DATA DICTIONARY 



ELEMENT 


TYPE 


WIDTH 


DESCRIPTION 


SHIP OBJECT 


Hull # 


:Alphanumeric 


5 


Ship’s Hull #. 


Ship's Name 


.•Alphanumeric 


15 


Ship's Name. 


Ship's Class 


:Alphanumeric 


15 


Ship's Class. 


CO's Name 


Alphanumeric 


25 


CO's Name. 


XO's Name 


: Alphanumeric 


25 


XO's Name. 


Higher Command 
DEPATRMENT 


:Alphanumeric 

•.DEPARTMENT 
object; MV 


10 


Higher Command that the 
ship belongs to. 


DEPARTMENT OBJECT 


Department Name 


:Alphanumeric 


15 


Name of the Department. 


Department Head 


Alphanumeric 


25 


Name of the Department 
Officer. 


Department Office Location 


Alphanumeric 


10 


Location of the 
Department Office. 


Department Phone # 
SHIP 

DIVISION 


Alphanumeric 
:SHIP object 
DIVISION 
object; MV 


5 


Department Office Phone ; 


DIVISION OBJECT 


Division Name 


Alphanumeric 


15 


Name of the Division. 


Division Officer Name 


Alphanumeric 


25 


Name of the 
Division Officer. 


Division Office Location 


Alphanumeric 


10 


Location of the 
Division Office. 


Division Phone # 
PERSON 

DEPARTMENT 


Alphanumeric 
•.PERSON 
object; MV 
DEPARTMENT 
object 


5 


Division Office Phone #. 
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PORT DUTY STATION OBJECT 



Port Duty Station Name 

Location 

Phone # 

PERSON 

PERSON OBJECT 

Personal ID # 

Last Name 
First Name 
Rank 

Rate 

Current Position 
Previous Position 
Date of Change 

Specialty 

1/3 Crew Division Number 
1/2 Crew Division Number 
Session Number 
Date of Birth 
Address 

Nearest Police Station 
& Phone # 

Berthing 



Alphanumeric 


15 


Alphanumeric 


10 


Alphanumeric 
: PERSON 
object; MV 


5 


Alphanumeric 


10 


Alphanumeric 


15 


Alphanumeric 


15 


Alphanumeric 


1 


Alphanumeric 


7 


Alphanumeric 


15 


Alphanumeric 


15 


:Date 


6 


Alphanumeric 


15 


Alphanumeric 


1 


Alphanumeric 


1 


Alphanumeric 


1 


.Date 


6 


Alphanumeric 


30 


Alphanumeric 


50 


Alphanumeric 


10 



Name of the 
Port Duty Station. 
Location of the 
Port Duty Station. 

Port Duty Station Phone # 



Person’s 

Identification Number. 
Person’s Last Name. 
Person’s First Name. 
Person’s Rank: 

O: if Officer, 

P: if Pety Of., 

S: if Sailor. 

Person's Rate. 
Crewmember Current 
Position of his Job. 
Crewmember Previous 
Position of his Job. 
mm/dd/yy 

Date of Change from 
Previous Position to 
Current Position. 

Person’s Specialty. 
Number of "1/3 
Crew Division System". 
Number of "1/2 
Crew Division System". 
Number of XO’s 
Daily Session. 

Person's DoB, 
mm/dd/yy. 

Person's Home Address. 

Police Station 

closest to Person’s Home. 

Person's Berthing Place. 
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Air Control Category 


:Alphanumeric 1 


Category of the 
Air Controller. 

(if the person is, 
"N" if he is not). 


Instructor Air Controller 


Alphanumeric 1 


"Y" if he is Instructor, 
"N" if he is not. 


Religion 


Alphanumeric 12 


Person's Religion. 


Education 


: Alphanumeric 12 


Person's Undergraduate 
Education. 


Foreign Languages 


Alphanumeric 25 


Foreign Languages 
spoken by the Person. 


Hobbies 


Alphanumeric 25 


Person’s Hobbies. 


TRAINING 


: TRAINING 
object; MV 




OJT EVALUATION 


:OJT EVALUATION 
object; MV 




DEPENDENT 


DEPENDENT 

object 




PROMOTION 


PROMOTION 
object; MV 




FITNESS EVALUATION 


WITNESS 

EVALUATION 

object 




DIVISION 


DIVISION object 




DISCIPLINARY 


:DISCIPLINARY 
object; MV 




ABNDON SHIP STATION 


ABANDON SHIP 
STATION object 




SPECIAL STATION 


: SPECIAL STATION 
object; MV 




SPECIAL DUTY 


: SPECIAL DUTY 
object; MV 




REQUEST 


:REQUEST 
object; MV 




LEAVE 


:LEAVE object; MV 




AIR CONTROL CHECK 


AIR CONTROL 
CHECK object; MV 




PORT DUTY STATION 


TORT DUTY 
STATION object 
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DEPENDENTS OBJECT 



Dependent's Name 


Alphanumeric 


25 


Name of Person's 
Closest Dependent. 


Dependent's Address 


: Alphanumeric 


25 


Address of the 
Dependent. 


Dependent's Phone # 


Alphanumeric 


10 


Dependent's Phone #. 


Other Dependents' Name 
PERSON 


Alphanumeric 
:PERSON object 


30 


Names of Other 
Possible Dependents. 


DISCIPLINARY OBJECT 


Offence # 


Alphanumeric 


4 


Number of the 
Offence : "mmdd" . 


Offence Name 


Alphanumeric 


20 


Name of the Offence. 


Date of Offence 


:Date 


6 


mm/dd/yy 


Apology 


:Memo 


100 


Person's Apology. 


Punishment 


Alphanumeric 


3 


Imposed Punishment. 


Start Date 


:Date 


6 


mm/dd/yy 


End Date 


:Date 


6 


mm/dd/yy 


Reporting Officer 
PERSON 


Alphanumeric 
: PERSON object 


25 


Name of the 
Reporting Officer. 


PROMOTION OBJECT 


Promotion Date 


:Date 


6 


mm/dd/yy 


Command Issued the Order 


Alphanumeric 


10 


Higher Command 
Issued the Promotion Order. 


Date of Issued Order- 
PERSON 


:Date 

:PERSON object 


6 


mm/dd/yy 


FITNESS EVALUATION OBJECT 


Reference Period 


Alphanumeric 


4 


Period that Fitness 
Evaluation is referred to: 
(mmyy). 


Start Date 


:Date 


6 


mm/dd/yy 


End Date 


:Date 


6 


mm/dd/yy 


Grade 


Alphanumeric 


1 


"P":if Pass; 
"F":if Fail. 
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Comments 

PERSON 


:Memo 

:PERSON object 


50 


Any possible comments. 


OJT EVALUATION OBJECT 


Start Date 


:Date 


6 


mm/dd/yy 


End Date 


:Date 


6 


mm/dd/yy 


Grade 


:Alphanumeric 


1 


"P":if Pass; 
"F":if Fail. 


Comments 


:Memo 


50 


Any possible comments. 


Station Duty of Qualification 
Officer Performed the 


:Alphanumeric 


15 


Duty Station that Person is 
Qualified for. 


Qualification 

PERSON 


:Alphanumeric 
: PERSON object 


25 


Name of the Officer 
Performed the Qualification. 


TRAINING OBJECT 


School 


:Alphanumeric 


15 


School that Person 
has Participated. 


Date 


:Date 


6 


mm/dd/yy 


Degree/Diploma 


:Alphanumeric 


20 


Degree or Diploma 
achieved. 


No. of Participants 


rAlphanumeric 


2 


Number of Persons 
Participated at the 
specific School. 


Grade 

Order of Success 


:Alphanumeric 


3 


Grade achieved 
in percentage % 


among Participants 


:Alphanumeric 


2 


Person's Order of Success 
among the Participants. 


Comments 

PERSON 


:Memo 
: PERSON 
object; MV 


50 


Any possible comments. 


AIR CONTROL CHECK OBJECT 


Date 


:Date 


6 


mm/dd/yy 


Time 


:Alphanumeric 


4 


Time that Control was 
performed (hhmm). 


Type of Aircraft 


:Alphanumeric 


10 


Type of Aircraft Controlled. 
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Type of Control 


:Alphanumeric 


1 


Type of Control 
for the Flight; 

"P" :Positive; 

"A" Advisory; 

"T" :Tactical Directions; 
"F" :Free/No Control. 


Duration of Control 


:Alphanumeric 


4 


Duration time of Control 
(hhmm). 


Comments 

PERSON 


:Memo 

:PERSON object 


50 


Any possible comments. 


LEAVE OBJECT 


Date Starts 


.Date 


6 


mm/dd/yy 


Date Ends 


:Date 


6 


mm/dd/yy 


Type of Leave 


Alphanumeric 


15 


Type of Leave. 


No. of Days 


.•Alphanumeric 


2 


No. of Days on Leave. 


Destination 


Alphanumeric 


25 


Location of the Person 
during his Leave. 


Comments 

PERSON 


:Memo 

: PERSON object 


50 


Any possible comments. 


REQUEST OBJECT 


Type of Request 


Alphanumeric 


15 


Type of Request that a 
Person could have. 


Date 


•.Date 


6 


mm/dd/yy 


Description 


:Memo 


30 


Short Description of 
Person's Request. 


CO's Decision 


Alphanumeric 


1 


CO's Decision; 

"Y" if Yes, "N" in No. 


Comments 

PERSON 


:Memo 

:PERSON object 


50 


Any possible comments. 


SPECIAL DUTY OBJECT 


Type of Duty 


Alphanumeric 


20 


Type of Special Duty. 


Duty Title 


Alphanumeric 


15 


Title of Special Duty. 


Duty Instructions 


:Memo 


30 


Given Special Instructions. 


Equipment/Gun+Amo 


:Memo 


30 


Any Equipments, 
Gun+Amo carried. 


Gathering Position 


Alphanumeric 


10 


Location of the 
Gathering Station. 



73 



PERSON :PERSON 

object; MV 

SPECIAL STATION OBJECT 



Station Type 

Title 

Duty 

Equipment 

Gathering Position/Location 



Alphanumeric 

•.Alphanumeric 

Alphanumeric 

:Memo 

Alphanumeric 



PERSON 



: PERSON 
object; MV 



ABANDON SHIP STATION OBJECT 



Station Number Alphanumeric 

Location Alphanumeric 

Type of Rescue Vessel Alphanumeric 

Capacity :Number 



20 

15 

20 

30 

10 



3 

10 

20 

2 



PERSON 



.PERSON object 



Type of Special Station. 
Title of Special Station. 
Assigned Duty. 

Any Equipments carried. 
Location of the 
Gathering Station. 



Number of the Abandon 
Ship Station. 

Location of the Station. 

Type of the Rescue Vessel. 
Capacity of the 
Rescue Vessel. 
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APPENDIX C: DATA FLOW DIAGRAMS 
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Project : B:\DFD\ 

Chart : context 
Filename : context. dfd 
Last modified on : Apr -27- 1994 
by User : Tsongas George 



ADMINISTRATION 

OFFICE 

PERSONNEL 



Request 



Responce 



1 




PROCESS 0 

SPAS CONTEXT DIAGRAM 
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: B:\DFD\ 

Ivllsys 

f : Ivllsys.dfd 
lified on : Apr- 27- 1994 
: Tsongas George 




COMMANDING 

OFFICER 







tSONNEl DATA PROCESSED; REQUEST INFORMATION 



SPAS D.B. 



PROCESSES 1,2,3 
LEVEL ONE 
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HIGHER 

COMMAND 



Project : B:\DFD\ 

Chart : Ivl2p1 
Filename : Ivl2p1.dfd 
Last modified on : Apr- 27- 1994 
by User : Tsongas George 




! j 



_i i i 

SPAS D.B. 
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: B: \DFD\ 

Ivl2p2 

e : l vl2p2.dfd 
dified on : Apr- 27- 1994 
r : Tsongas George 



SPECIAL REQUEST 


CREWMEMBER 


LEAVE REQUEST 


r 





I 

I 

( 



2.1 P 
PROCESS 
SPECIAL 
REQUEST 







2.2 P 
PROCESS 
LEAVE 
REQUEST 



PROCESSED 

SPECIAL 
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[fence # 
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siplinary 
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O. Date 
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End Date 



Reporting Officer 



Promotion Pate 



Promotion 
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CMD issued the Order 



Date of Issued Order 



Nearest Police Station and Phone # 



Previous Position 


Date of Change 


Division Name” 


Port Duty Station Name” 


continue... 



-Pol 



Port Dutv station _N ame 


Location 
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Port Duty Station 
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Date 
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Order among Participants 



Comments 
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APPENDIX F: APPLICATION INPUT FORMS 
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APPENDIX G: APPLICATION REPORTS 



mm/dd/yy 



Personal Information Card 



Page 9 



Personal ID #: AAAAAAAAAA 

Last Name : AAAAAAAAAAAAAAA 
First Name: AAAAAAAAAAAAAAA 

Rank: A Rate: AAAAAAA 

Specialty: AAAAAAAAAAAAAAA 

Abandon Ship Station #: AAA 

1/3 Crew Division System: A 
1/2 Crew Division System: A 
Session: A 

Special Station Type: AAA 
Title: AAAAAAAAAAAAAAAAAAAA 
Duty: AAAAAAAAAAAAAAAAAAAA 
Equipment: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Gathering Position: AAAAAAAAAA 

Type of Special Duty: AAAAAAAAAAAAAAAAAAAA 
Duty Title: AAAAAAAAAAAAAAA 

Duty Instructions: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Equipment /Gun + Amo : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Gathering Position: AAAAAAAAAA 



Division Name: AAAAAAAAAAAAAAA 

Port Duty Station Name: AAAAAAAAAAAAAAA 



Current Posision: AAAAAAAAAAAAAAA 
Berthing: AAAAAAAAAA 

Location: AAAAAAAAAA 



Personal Information Card Format 



mm/dd/yy 



Personnel Fitness Evaluation Report 



Page 9 



Personal ID #: AAAAAAAAAA Rank: A Reference Period :AAAA 

Last Name : AAAAAAAAAAAAAAA Rate: AAAAAAA Grade: A 

First Name: AAAAAAAAAAAAAAA Special ty : AAAAAAAAAAAAAAA 

Date of Birth: mm/dd/yy 

Start Date: mm/dd/yy End Date: mm/dd/yy 

Comments; AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Fitness Evaluation Report Forrmat 
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mm/dd/yy 



Personal ID 
AAAAAAAAAA 



Officer's Special Report 



Pace 9 



Address 

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Last / First Name Rate 
AAAAAAAAAAAAAAA AAAAAAA 
AAAAAAAAAAAAAAA Rank: A 
Specialty: AAAAAAAAAAAAAAA 

Nearest Police station & phone Nr. : 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 



Officer's Special Report Format 



mm/da/yy Officers' Monthly Report Page 9 



Person ID Rank Rate Last Name Current Pos. Address 

AAAAAAAAAA A AAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA 

First Name Previous Pos. 

Specialty AAAAAAAAAAAAAAA AAAAAAAAAAAAAAA 
AAAAAAAAAAAAA Date of Change 

mm/dd/yy 



Officer's Monthly Report Format 



mm/dd/yy 



Petty Officers' Monthly Report 



Page 9 



Last Name Rank Rate 
AAAAAAAAAAAAAAA A AAAAAAA 
First Name 
AAAAAAAAAAAAAAA 



Person ID Current Pos . 
AAAAAAAAAA AAAAAAAAAAAAAAA 
Specialty 
AAAAAAAAAAAAAAA 



Address 

AAAAAAAAAAAAAAAAAAAAAAAA 
Near Police Station 
AAAAAAAAAAAAAAAAAAAAAAAA 



Petty Officer’s Monthly Report Format 
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mm/dd/yy 1/2 Crew Division System Page 5 



Division Person ID Last Name First Name Rank Rate Specialty 

A AAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAA A AAAAAAA AAAAAAAAAAAAAA 



1/2 Crew Division System Report Format 



mm/dd/yy 1/ 3 Crew Division System 

Division Person ID Last Name First Name Rank 


Rate 


Page 9 
Specialty 


A AAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAA A 


AAAAAAA 


AAAAAAAAAAAAAA 


1/3 Crew Division System Report Format 


rnm. dd/vy XC's Daily Division System Report: 




Page 9 


Session Person ID Last: Name First Name Rank 


Rate 


Specialty 


A AAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAA A 


AAAAAAA 


AAAAAAAAAAAAAA 


XO Daily Session Division System Report Format 
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mm/dd/yy 


Aier 


t Station Report 


Page 9 


Last/First Name 


Rank Rate 


Div. : 


Tide 






A AAAAAAA 


1/3 : A 


AAAAAAAAAAAAAAAAAAAA 


Location 


AAAAAAAAAAAAAAA 


Specialty 


1/2 : A 


Ducy 


AAAAAAAAAA 


AAAAAAAAAAAAAAA 


AAAAAAAAAAAAAAA 




AAAAAAAAAAAAAAAAAAAA 




Berthing : 


AAAAAAAAAA 









Alert Station Report Format 



mm/dd/vy 



Last/First: Name 



Special Station Report 



Rank Rate 
A AAAAAAA 
Specialty 



Div. : Title 

1/3 :A AAAAAAAAAAAAAAAAAAAA 

1/2 :A Duty 

AAAAAAAAAAAAAAAAAAAA 



Page 9 



Locat ion 
AAAAAAAAAA 



AAAAAAAAAAAAAAA 

AAAAAAAAAAAAAAA AAAAAAAAAAAAAAA 
Berthing: AAAAAAAAAA 

Equipment: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Special Station Report Format 



mm, dd/yy 



Abandon Ship Stations 



Page 9 



Station 4 Location 
AAA 



Rescue Vessel 



Cap/tv Last^First Name Rank Rate 



z\aAAAAAAAA AAAAAAAAAAAAAAAAAAAA 999999 AAAAAAAAAAAAAAA A AAAAAAA 

AAAAAAAAAAAAAAA 



Abandon Ship Station Report Format 
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mm/dd/yy Personal Information 300K / RECORD Page 9 

Hull #: AAAAA Ship's Name: AAAAAAAAAAAAAAA Ship's Class: AAAAAAAAAAAAAAA 
Department Name: AAAAAAAAAAAAAAA Division Name: AAAAAAAAAAAAAAA 

Personal ID #: AAAAAAAAAA Last/First Name: AAAAAAAAAAAAAAA, AAAAAAAAAAAAAAA 
Rank: A Rate: AAAAAAA Specialty: AAAAAAAAAAAAAAA Date of Birth : dd/mm/yv 

Division Name: AAAAAAAAAAAAAAA Port Duty Station Name: AAAAAAAAAAAAAAA 

Abandon Ship Station #: AAA 

Current Posision: AAAAAAAAAAAAAAA 

Previous Position: AAAAAAAAAAAAAAA Date of Change: mm/dd/yy 

1/3 Crew Division System: A 
1/2 Crew Division System: A 
Session: A 

Address: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

Near Police St . 5c phone #: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Religion: AAAAAAAAAAAA Hobbies: AAAAAAAAAAAAAAAAAAAAAAAAA 

Education: AAAAAAAAAAAA Foreign Languages: AAAAAAAAAAAAAAAAAAAAAAAAA 

School: AAAAAAAAAAAAAAA Date: mm/dd/yy 
Degree/Diploma: AAAAAAAAAAAAAAAAAAAA 

Comments : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

Promotion Date: mm/dd/yy 

Command Issued the Order: AAAAAAAAAA 

Date of Issued Order: mm/dd/yy 

Type of Leave: AAAAAAAAAAAAAAA 

Date Starts: mm/dd/yy Date Ends: mm/dd/yy No. of Days: AA 
Comments- 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

Offence #: AAAA Offence Name: AAAAAAAAAAAAAAAAAAAA 

Date of Offence: mm/dd/yy Punishment: AAA 

Type of Duty: AAAAAAAAAAAAAAAAAAAA Duty Title: AAAAAAAAAAAAAAA 

Duty Instructions: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Personal Information BOOK / RECORD 



mm, 

» 

i 

I 

i 

♦ 



dc/yy 



Air Control Monthly Report 



Page 9 



I Las; Name: AAAAAAAAAAAAAAA 
I Rar.K : A Rate : AAAAAAA 

Air Control Category: A 



First Name : AAAAAAAAAAAAAAA 
Specialty: AAAAAAAAAAAAAAA 
Instructor Air Contrcler: A 



Date, mm/dd/yy 

* 1 me : AAArt 



Type of A/C 

AAAAAAAAAA Type of Control: A Duration of Control: AAAA 



Comments: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Air Control Monthly Report Format 
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mm/dd/yy 



Sailors' Monthly Report 



Last Name Rank Rate Person ID Current Pcs. Address 

aaaaaaaaaaaaaaa a aaaaaaa aaaaaaaaaa aaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa 
First Name Specialty Near Police Station 

AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA 



Sailor's Monthly Report Format 


mm / da / yy 


Sail 


crs' Punishment 


Monthly Report 


Page 9 


Person ID 


Last Name 


Rate 


Offence # and Name 


Date 


AAAAAAAAAA 


AAAAAAAAAAAAAAA 


AAAAAAA 


AAAA AAAAAAAAAAAAAAAAAAAA 


dd/mm/yy 




First, Name 


Specialty 








AAAAAAAAAAAAAAA 


AAAAAAAAAAAAAAA 


Punishment : AAA 





Sailor's Punishment Monthly Report Format 
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APPENDIX H: SYSTEM'S PROGRAM AND CODE 



A. PART ONE: DOCUMENTATION OF MENU STRUCTURE 
SPAS - Shipboard Personnel Administration System 
Menu Tree 

Documentation of Menu Structure 



MAIN 

— PERSONNEL SUBSYSTEM Enter All Personal Data to the System 
S — PROCESS CREWMEMBER DATA Enters Crewmember Data to the System 

— PROCESS DEPENDENT DATA Enters Crewmembers’ Dependent Data to the System 

— PROCESS DISCIPLINARY DATA Enters Crewmembers' Disciplinary Data to the System 

— PROCESS EVALUATION DATA Enters Crewmembers' Evaluation Data 

— PROCESS OJT EVALUATION DATA Enters Crewmembers’ OJT Evaluation Data 
— PROCESS FITNESS EVALUATION DATA Enters Crewmembers' Fitness Data 

— MAINTAIN PERSON DATA Updates all Personnel Data 

— UPDATE AIR CONTROL DATA Keeps Track of Air Control Data 
— UPDATE PROMOTION DATA Updates Personnel Promotion Data 
— UPDATE CREWMEMBER DATA Updates Crewmembers' Personal Data 
— ADD DATA Adds Crewmember Data 
| — MODIFY DATA Modifies Crewmember Data 

— DELETE DATA Deletes Crewmember Data 
— UPDATE DEPENDENT DATA Updates Crewmembers' Dependent Data 
— ADD DATA Adds Dependents Data 
— MODIFY DATA Modifies Dependents Data 
DELETE DATA Deletes Dependents Data 
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— UPDATE DISCIPLINARY DATA Updates Crewmembers' Disciplinary Data 
— ADD DATA Adds Disciplinary Data 

— MODIFY DATA Modifies Disciplinary Data 
' — DELETE DATA Deletes Disciplinary Data 

— UPDATE EVALUATION DATA Updates Crewmembers' Evaluation Data 

— ADD DATA Adds Evaluation Data 

— MODIFY DATA Modifies Evaluation Data 

— DELETE DATA Deletes Evaluation Data 
REQUEST SUBSYSTEM Handle Personnel Requests 

— PROCESS SPECIAL REQUEST Enters the System Crewmembers' Special Requests 

— PROCESS LEAVE REQUEST Enters the System Crewmembers' Leave Requests 
REPORT SUBSYSTEM Generates All the Reports 

— ANSWER SPECIFIED QUERIES Answer Queries 

— QUERY PERSON AND DEPENDENT Query Crewmember and his Dependent Data 

— QUERY PERSON AND SPECIAL STATION Query Crewmember and his Special Station Data 

— QUERY PERSON AND DIVISION SYSTEM Query Crewmember and his Division Data 

— QUERY PERSON ,TRAINING,EV ALU ATION Query Crewmember's Training and Evaluation Data 

11 I 

— PERSON,REQUEST,LEAVE,OJT,DISCIPL Query Crewmember and his Request, Leave, OJT 

Evaluation and Disciplinary 

j— PRODUCE INTERNAL REPORTS Produce Reports for Ship's Use 
| 1 — PERSONAL INFORMATION CARD Produce Personal Information Card 

1 — PERSONAL INFORMATION BOOK Produce Personal Information Book 
! ; — FITNESS EVALUATION REPORT Produce Crewmembers' Fitness Evaluation Report 

— DIVISION SYSTEM REPORT Produce Division Systems Reports 

■ — 1/3 SYSTEM Produce 1/3 Crew Division System Report 

| 

* — 1/2 SYSTEM Produce 1/2 Crew Division System Report 
— SESSION SYSTEM Produce Session Division System Report 

— SPECIAL DUTY STATION REPORT Produce Special Stations Reports 
I — ALERT STATION Produce Alert Station Report 
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| — MOOR-ANCHO-TOW STATION Produce Ship’s Maneuvers Station Report 

^ — ABANDON SHIP STATION Produce Abandon Ship Station Report 
— PRODUCE EXTERNAL REPORTS Produce Reports for Higher Commands 

— AIR CONTROLLER MONTHLY REPORT Produce A/C Monthly Report 

— OFFICER SPECIAL REPORT Produce Officers' Special Report 

— OFFICER MONTHLY REPORT Produce Officers' Monthly Report 

— PETTY OFFICER MONTHLY REPORT Produce Petty Officers' Monthly Report 

— SAILOR MONTHLY REPORT Produce Sailors' Monthly Report 

— SAILOR PUNISHMENT MONTHLY REPORT Produce Sailors' Punishment Monthly Report 

— EXIT Exit the System 

— EXIT TO PARADOX Exit this Application but stays in PARADOX 
<Separator> 

— EXIT TO DOS Exits PARADOX and Goes to DOS 



B. PART TWO: DOCUMENTATION OF ACTION MENU 

SPAS - Shipboard Personnel Administration System 



Edit Session: SN11A 



Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: PERSON 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins,Edit 

On Tablelist: 

Prompt: Enters the System Personal Data 



Edit Session: SN11B 



Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: PROMOTIO 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: InsJEdit 

On Tablelist: 

Prompt: Enters the System Person's Promotion Data 
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Edit Session; SN11C 



Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: PERSTATN 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins,Edit 

On Tablelist: 

Prompt: Assigns Person to Special Stations 



Edit Session: SN11D 



Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: PERSDUTY 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins,Edit 

On Tablelist: 

Prompt: Assigns Person to Special Duties 



Edit Session: SN12 



Mode DataEntry 
Passwords As Needed 
Prompt 

Tables Declared: 1 
Table 1: DEPENDEN 
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Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins,Edit 

On Tablelist: 

Prompt: Enters the System Person's Dependent Data 



Edit Session: SN124 



Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: FITNESS 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins, Edit 

On Tablelist: 

Prompt: Enter to the System All Personnel Fitness Evaluation Data 



Edit Session: SN13 



Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1 : DESCIPLN 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins,Edit 

On Tablelist: 

Prompt: 
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Edit Session: SN141 



Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: OJT-EVAL 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins,Edit 

On Tablelist: 

Prompt: Enters the System Personal OJT Evaluation Data 



Edit Session: SN151 



Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: AIR-CTRL 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins,Edit 

On Tablelist: 

Prompt: Enters the System Air Control Data 



Edit Session: SN152 



Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: PROMOTIO 



Initial View: Form 
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Allowed Views: Form 
Use Form: 1 

Modes: Ins.Update 

On Tablelist: 

Prompt: Updates Personnel Promotion Data 

Edit Session: SN1531 



Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: PERSON 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins,Update 

On Tablelist: 

Prompt: Adds Crewmember Data 



Edit Session: SN1532 



Mode: Edit 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: PERSON 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Edit 

On Tablelist: 

Prompt: Modifies Crewmember Data 



Edit Session: SN1533 



Mode: Edit 

Passwords: As Needed 
Prompt: 
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Tables Declared. 1 



Table 1: PERSON 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Del.Edit 

On Tablelist: 

Prompt: Deletes Crewmember Data 



Edit Session. SN1541 



Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: DEPENDEN 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins, Update 

On Tablelist: 

Prompt: Adds Dependent Data 



Edit Session: SN1542 



Mode: Edit 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1 : DEPENDEN 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Edit 

On Tablelist: 

Prompt: Modifies Dependent Data 
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Edit Session: SN1543 



Mode: Edit 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: DEPENDEN 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Del, Edit 

On Tablelist: 

Prompt: Deletes Dependent Data 



Edit Session: SN1551 



Mode DataEntry 
Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: DESCIPLN 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins,Update 

On Tablelist: 

Prompt: Adds Disciplinary Data 



Edit Session: SN1552 



Mode: Edit 

Passwords: As Needed 
Prompt: 
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Tables Declared: 1 



Table 1: DESCIPLN 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Edit 

On Tablelist: 

Prompt: Modifies Disciplinary Data 



Edit Session: SN1553 



Mode; Edit 
Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: DESCIPLN 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Del,Edit 

On Tablelist: 

Prompt: Deletes Disciplinary Data 

E dit Session: SN1561 

Mode: DataEntry 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: OJT-EVAL 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins, Update 

On Tablelist: 

Prompt: Adds OJT Evaluation Data 
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Edit Session: SN1562 



Mode; Edit 
Passwords; As Needed 
Prompt: 

Tables Declared; 1 
Table 1: OJT-EVAL 



Initial View; Form 
Allowed Views: Form 
Use Form: 1 

Modes: Edit 

On Tablelist: 

Prompt: Modifies OJT Evaluation Data 



Edit Session SN1563 



Mode: Edit 

Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: OJT-EVAL 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: DefEdit 

On Tablelist: 

Prompt. Deletes OJT Evaluation Data 



Edit Session: SN21 

Mode: DataEntry 

Passwords: As Needed 
Prompt. 

Tables Declared: 1 
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Table 1: REQUEST 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins,Edit 

On Tablelist: 

Prompt: 

Edit Session: SN22 

Mode. DataEntry 
Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: LEAVE 



Initial View: Form 
Allowed Views: Form 
Use Form: 1 

Modes: Ins, Edit 

On Tablelist: 

Prompt: 



Edit Session: SN31 1 



Mode: DataEntry 

Passwords: As Needed 

Prompt: Enter the Crewmember Last/First Name 



Tables Declared: 1 
Table 1: AD-HOC 



Initial View: Form 
Allowed Views: Form 
Use Form: F 

Modes: Ins,Edit 

On Tablelist: 

Prompt: 

Mode: DataEntry 



Edit Session: SN312 
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Passwords: As Needed 

Prompt: Enter the Crewmember. Last/First Name 

Tables Declared: 1 
Table 1: AD-HOC 



Initial View: Form 
Allowed Views: Form 
Use Form: F 

Modes: Ins,Edit 

On Tablelist: 

Prompt: 



Edit Session: SN313 



Mode: DataEntry 

Passwords: As Needed 

Prompt: Enter the Crewmember Last/First Name 

Tables Declared: 1 
Table 1: AD-HOC 



Initial View: Form 
Allowed Views: Form 
Use Form: F 

Modes: Ins,Edit 

On Tablelist: 

Prompt: 



Edit Session. SN314 



Mode: DataEntry 

Passwords. As Needed 

Prompt: Enter the Crewmember Last/First Name 

Tables Declared: 1 
Table 1: AD-HOC 



Initial View: Form 
Allowed Views: Form 
Use Form: F 

Modes: Ins, Edit 
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On Tablelist: 
Prompt: 



Edit Session: SN315 



Mode: DataEntry 

Passwords: As Needed 

Prompt: Enter the Crewmember Last/First Name 

Tables Declared: 1 
Table 1: AD-HOC 



Initial View: Form 
Allowed Views: Form 
Use Form: F 

Modes: Ins,Edit 

On Tablelist: 

Prompt: 



Multiple Actions: MA11 

Actions Called: 

1 ) Edit Session: SN11A 

2) Edit Session: SN11B 

3) Edit Session: SN11C 

4) Edit Session: SN11D 

[X] Quit if Action fails 



Multiple Actions: MA311 

Actions Called: 

1 ) Edit Session: SN311 

2) Play a Script: Adhocl 

3) Report Print: PRN311 

4) Play a Script: Empty 

[X] Quit if Action fails 
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Multiple Actions: MA312 



Actions Called: 

1) Edit Session: SN312 

2) Play a Script: Adhoc2 

3) Report Print: PRN312 

4) Play a Script: Empty 

[X] Quit if Action fails 



Multiple Actions: MA313 

Actions Called: 

1) Edit Session: SN313 

2) Play a Script: Adhoc3 

3) Report Print: PRN313 

4) Play a Script: Empty 

[X] Quit if Action fails 



Multiple Actions: MA314 

Actions Called: 

1) Edit Session: SN314 

2) Play a Script: Adhoc4 

3) Report Print: PRN314 

4) Play a Script: Empty 

[X] Quit if Action fails 



Multiple Actions: MA315 

Actions Called: 

1) Edit Session: SN315 

2) Play a Script: Adhoc5 

3) Report Print: PRN315 

4) Play a Script: Empty 
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[X] Quit if Action fails 



Multiple Actions: MA316 



Actions Called: 

1) Play a Script: Q321 

2) Report Print: PRN321 

[X] Quit if Action fails 



Multiple Actions: MA322 



Actions Called: 

1) Play a Script: Q322 

2) Report Print: PRN322 

[X] Quit if Action fails 



Multiple Actions: MA323 



Actions Called: 

1) Play a Script: Q323 

2) Report Print: PRN323 

[X] Quit if Action fails 



Multiple Actions: MA324A 



Actions Called: 

1) Play a Script: Q324a 

2) Report Print: PRN324A 

[X] Quit if Action fails 



Multiple Actions: MA324B 
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Actions Called. 



1) Play a Script: Q324b 

2) Report Print: PRN324B 

[X] Quit if Action fails 



Multiple Actions: MA324C 



Actions Called: 

1) Play a Script: Q324c 

2) Report Print: PRN324C 

[X] Quit if Action fails 



Multiple Actions: MA325A 



Actions Called: 

1) Play a Script: Q325a 

2) Report Print: PRN325A 

[X] Quit if Action fails 



Multiple Actions: MA325B 



Actions Called: 

1) Play a Script: Q325b 

2) Report Print: PRN325B 

[X] Quit if Action fails 



Multiple Actions: MA325C 



Actions Called: 

1) Play a Script: Q325c 

2) Report Print: PRN325C 

[X] Quit if Action fails 
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Multiple Actions: MA331 



Actions Called: 

1) Play a Script: Q331 

2) Report Print: PRN331 

[X] Quit if Action fails 



Multiple Actions: MA332 

Actions Called: 

1) Play a Script: Q332 

2) Report Print: PRN332 

[X] Quit if Action fails 



Multiple Actions: MA333 



Actions Called: 

1) Play a Script: Q333 

2) Report Print: PRN333 

[X] Quit if Action fails 



Multiple Actions: MA334 



Actions Called: 

1) Play a Script: Q334 

2) Report Print: PRN334 

[X] Quit if Action fails 



Multiple Actions: MA335 



Actions Called: 

1) Play a Script: Q335 

2) Report Print: PRN335 
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[X] Quit if Action fails 



Multiple Actions: MA336 



Actions Called: 

1) Play a Script: Q336 

2) Report Print: PRN336 

[X] Quit if Action fails 



Report Print: PRN311 



Table: ANSWER 

Report #: R 

Use Data From: Listed Table 

Output Devices: Screen 

Display Working Message: Yes 

Working Message: Here is the Requested Data 

Printer Port: Default 

Page Break: Default 

Prefix String: None 

Suffix String: None 

Setup Proc: None 

Cleanup Proc: None 



Report Print: PRN312 



Table ANSWER 
Report U. R 

Use Data From: Listed Table 

Output Devices: Screen 

Display Working Message: Yes 

Working Message: Here is the Requested Data 

Printer Port: Default 

Page Break: Default 
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Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


None 

None 

None 

None 


Table: ANSWER 

Report #: R 


Report Print: PRN313 


Use Data From: 
Output Devices: 


Listed Table 
Screen 



Display Working Message: Yes 

Working Message: Here is the Requested Data 

Printer Port: Default 



Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

None 

None 

None 

None 


Table: ANSWER 

Report #: R 


Report Print: PRN314 


Use Data From: 
Output Devices: 


Listed Table 
Screen 



Display Working Message: Yes 

Working Message: Here is the Requested Data 



Printer Port: 
Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

Default 

None 

None 

None 

None 


Table: ANSWER 

Report #: R 


Report Print: PRN315 
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Use Data From: 


Listed Table 


Output Devices: 


Screen 


Display Working Message: Yes 


Working Message: 


Here is the Requested Data 


Printer Port: 


Default 


Page Break: 


Default 


Prefix String: 


None 


Suffix String: 


None 


Setup Proc: 


None 


Cleanup Proc: 


None 



Table: T321 

Report #: 1 


Reoort Print: PRN321 


Use Data From: 


Listed Table 


Output Devices: 


Screen, Printer 


Display Working Message: Yes 


Working Message: 


Personal Information Card ... 


Printer Port: 


Default 


Page Break: 


Default 


Prefix String: 


None 


Suffix String: 


None 


Setup Proc: 


None 


Cleanup Proc: 


None 



Table: T322 

Report #: 1 


ReDort Print: PRN322 


Use Data From: 


Listed Table 


Output Devices: 


Screen, Printer 


Display Working Message: Yes 


Working Message: 


Personal Info Book/Record ... 


Printer Port: 


Default 


Page Break: 


Default 


Prefix String: 


None 


Suffix String: 


None 


Setup Proc: 


None 


Cleanup Proc: 


None 
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Table: T323 

Report #: 1 



Report Print: PRN323 



Use Data From: Listed Table 

Output Devices: Screen, Printer 

Display Working Message: Yes 

Working Message: Personnel Fitness Evaluation Report. 

Printer Port: Default 



Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

None 

None 

None 

None 


Table: T324A 

Report #: 1 


Report Print: PRN324A 


Use Data From: 


Listed Table 



Output Devices: Screen, Printer 

Display Working Message: Yes 

Working Message: 1/3 Crew Division System Report 

Printer Port: Default 



Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

None 

None 

None 

None 


Table: T324B 

Report #: 1 


Report Print: PRN324B 


Use Data From: 
Output Devices: 


Listed Table 
Screen, Printer 



Display Working Message: Yes 

Working Message: 1/2 Crew Division System Report 

Printer Port: Default 



Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 


Default 

None 

None 

None 
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Cleanup Proc: 



None 



Report Print. PRN324C 

Table: T324C 

Report #: 1 

Use Data From: Listed Table 

Output Devices: Screen, Printer 

Display Working Message: Yes 

Working Message: Session Division Report ... 

Printer Port: Default 



Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

None 

None 

None 

None 



Table: T325A 

Report #: 1 


Report Print: PRN325A 


Use Data From: 
Output Devices: 


Listed Table 
Screen, Printer 



Display Working Message: Yes 
Working Message: Alert Station Report 



Printer Port: 
Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

Default 

None 

'None 

None 

None 



Report Print: PRN325B 



Table: T325B 

Report #: 1 

Use Data From: 


Listed Table 



Output Devices: Screen, Printer 

Display Working Message: Yes 
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Working Message: Special Station Report 



Printer Port: 
Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

Default 

None 

None 

None 

None 


Table: T325C 

Report #: 1 


Report Print: PRN325C 


Use Data From: 


Listed Table 



Output Devices: Screen, Printer 

Display Working Message: Yes 

Working Message: Abandon Ship Station Report 

Printer Port: Default 



Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

None 

None 

None 

None 


Table: T331 

Report #: 1 


Report Print: PRN331 


Use Data From: 


Listed Table 



Output Devices: Screen, Printer 

Display Working Message: Yes 

Working Message: Air Control Monthly Report 

Printer Port: Default 



Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

None 

None 

None 

None 


Table: T332 

Report #: 1 


Report Print: PRN332 
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Use Data From: Listed Table 

Output Devices: Screen, Printer 

Display Working Message: Yes 
Working Message: Officer Special Report 



Printer Port: 
Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

Default 

None 

None 

None 

None 


Table: T333 

Report #: 1 


Report Print: PRN333 


Use Data From: 


Listed Table 



Output Devices: Screen, Printer 

Display Working Message: Yes 
Working Message: Officers' Monthly Report 

Printer Port: Default 



Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

None 

None 

None 

None 


Table: T334 

Report #: 1 


Report Print: PRN334 


Use Data From: 


Listed Table 



Output Devices: Screen, Printer 

Display Working Message: Yes 

Working Message: Petty Officers' Monthly Report 



Printer Port: 
Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

Default 

None 

None 

None 

None 
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Table: T335 

Report #: 1 



Report Print: PRN335 



Use Data From: Listed Table 

Output Devices: Screen, Printer 

Display Working Message: Yes 
Working Message: Sailors’ Monthly Report. 

Printer Port: Default 



Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

None 

None 

None 

None 

Report Print: PRN336 


Table: T336 

Report #: 1 




Use Data From: 


Listed Table 



Output Devices: Screen, Printer 

Display Working Message: Yes 

Working Message: Sailors' Punishment Monthly Report. 

Printer Port: Default 



Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Default 

None 

None 

None 

None 



140 



C. PART THREE: DOCUMENTATION OF CROSS-REFERENCE MENU 



SPAS - Shipboard Personnel Administration System 
Cross Reference 

Action Objects & Paradox Objects in Use 



Objects in the Menu & Object Tables: Referenced bv: 


Object Type 


Object Name 


Object Type 


Object Name 


Edit Session 


SN11A 


Multiple Actions MA11 


Edit Session 


SN11B 


Multiple Actions MA11 


Edit Session 


SN11C 


Multiple Actions MA11 


Edit Session 


SN11D 


Multiple Actions MA11 


Edit Session 


SN12 


Menu 


CFG\SPAS 


Edit Session 


SN124 


Menu 


CFG\SPAS 


Edit Session 


SN13 


Menu 


CFG\SPAS 


Edit Session 


SN141 


Menu 


CFG\SPAS 


Edit Session 


SN151 


Menu 


CFG\SPAS 


Edit Session 


SN152 


Menu 


CFG\SPAS 


Edit Session 


SN1531 


Menu 


CFG\SPAS 


Edit Session 


SN1532 


Menu 


CFG\SPAS 


Edit Session 


SN153 


Menu 


CFG\SPAS 


Edit Session 


SN1541 


Menu 


CFG\SPAS 


Edit Session 


SN1542 


Menu 


CFG\SPAS 


Edit Session 


SN1543 


Menu 


CFGVSPAS 


Edit Session 


SN1551 


Menu 


CFG\SPAS 


Edit Session 


SN1552 


Menu 


CFGVSPAS 


Edit Session 


SN1553 


Menu 


CFGVSPAS 


Edit Session 


SN1561 


Menu 


CFGNSPAS 


Edit Session 


SN1562 


Menu 


CFG\SPAS 


Edit Session 


SN1563 


Menu 


CFG\SPAS 


Edit Session 


SN21 


Menu 


CFG\SPAS 


Edit Session 


SN22 


Menu 


CFG\SPAS 


Edit Session 


SN311 


Multiple Actions MA311 


Edit Session 


SN312 


Multiple Actions MA312 


Edit Session 


SN313 


Multiple Actions MA313 


Edit Session 


SN314 


Multiple Actions MA314 


Edit Session 


SN315 


Multiple Actions MA315 


Exit Paradox 




Menu 


CFG\SPAS 


Form 


AD-HOC. F 


Edit Session 


SN311 






Edit Session 


SN312 






Edit Session 


SN313 






Edit Session 


SN314 






Edit Session 


SN315 



141 



Form 


AIR-CTRL.F1 


Edit Session 


SN151 


Form 


DEPENDENT 1 


Edit Session 


SN12 






Edit Session 


SN1541 






Edit Session 


SN1542 






Edit Session 


SN1543 


Form 


DESCIPLN.F1 


Edit Session 


SN13 






Edit Session 


SN1551 






Edit Session 


SN1552 






Edit Session 


SN1553 


Form 


FITNESS.F1 


Edit Session 


SN124 


Form 


LEAVE.F1 


Edit Session 


SN22 


Form 


OJT-EVAL.F1 


Edit Session 


SN141 






Edit Session 


SN1561 






Edit Session 


SN1562 






Edit Session 


SN1563 


Form 


PERSDUTY.F1 


Edit Session 


SN11D 


Form 


PERSON.F1 


Edit Session 


SN11A 






Edit Session 


SN1531 






Edit Session 


SN1532 






Edit Session 


SN1533 


Form 


PERSTATN.F1 


Edit Session 


SN11C 


Form 


PROMOTIO.F1 


Edit Session 


SN11B 






Edit Session 


SN152 


Form 


request.fi 


Edit Session 


SN21 



Multiple Actions MA11 
Multiple Actions MA311 
Multiple Actions MA312 
Multiple Actions MA313 
Multiple Actions MA314 
Multiple Actions MA315 
Multiple Actions MA321 
Multiple Actions MA322 
Multiple Actions MA323 
Multiple Actions MA324A 
Multiple Actions MA324B 
Multiple Actions MA324C 
Multiple Actions MA325A 
Multiple Actions MA325B 
Multiple Actions MA325C 
Multiple Actions MA331 
Multiple Actions MA332 
Multiple Actions MA333 
Multiple Actions MA334 
Multiple Actions MA335 
Multiple Actions MA336 
Play a Script ADHOC1 
Play a Script ADHOC2 



Menu CFG\SPAS 
Menu CFGVSPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFGVSPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Menu CFG\SPAS 
Multiple Actions MA3 1 1 
Multiple Actions MA312 
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Play a Script 


ADHOC3 


Multiple Actions 


MA313 


Play a Script 


ADHOC4 


Multiple Actions 


MA314 


Play a Script 


ADHOC5 


Multiple Actions 


MA315 


Play a Script 


EMPTY 


Multiple Actions 


MA311 






Multiple Actions 


MA312 






Multiple Actions 


MA313 






Multiple Actions 


MA314 






Multiple Actions 


MA315 


Play a Script 


Q321 


Multiple Actions 


MA321 


Play a Script 


Q322 


Multiple Actions 


MA322 


Play a Script 


Q323 


Multiple Actions 


MA323 


Play a Script 


Q324A 


Multiple Actions 


MA324A 


Play a Script 


Q324B 


Multiple Actions 


MA324B 


Play a Script 


Q324C 


Multiple Actions 


MA324C 


Play a Script 


Q325A 


Multiple Actions 


MA325A 


Play a Script 


Q325B 


Multiple Actions 


MA325B 


Play a Script 


Q325C 


Multiple Actions 


MA325C 


Play a Script 


Q331 


Multiple Actions 


MA331 


Play a Script 


Q332 


Multiple Actions 


MA332 


Play a Script 


Q333 


Multiple Actions 


MA333 


Play a Script 


Q334 


Multiple Actions 


MA334 


Play a Script 


Q335 


Multiple Actions 


MA335 


Play a Script 


Q336 


Multiple Actions 


MA336 



Procedure 
Quit to Paradox 



Application SPAS 
Menu CFG\SPAS 



Report 


ANSWER.R 


Report Print 


PRN311 






Report Print 


PRN312 






Report Print 


PRN313 






Report Print 


PRN314 






Report Print 


PRN315 


Report 


T321.R1 


Report Print 


PRN321 


Report 


T322.R1 


Report Print 


PRN322 


Report 


T323.R1 


Report Print 


PRN323 


Report 


T324A.R1 


Report Print 


PRN324A 


Report 


T324B.R1 


Report Print 


PRN324B 


Report 


T324C.R1 


Report Print 


PRN324C 


Report 


T325A.R1 


Report Print 


PRN325A 


Report 


T325B.R1 


Report Print 


PRN325B 


Report 


T325C.R1 


Report Print 


PRN325C 


Report 


T331.R1 


Report Print 


PRN331 


Report 


T332.R1 


Report Print 


PRN332 


Report 


T333.R1 


Report Print 


PRN333 


Report 


T334.R1 


Report Print 


PRN334 


Report 


T335.R1 


Report Print 


PRN335 


Report 


T336.R1 


Report Print 


PRN336 



Report Print PRN311 Multiple Actions MA311 

Report Print PRN312 Multiple Actions MA312 
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Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 



PRN313 

PRN314 

PRN315 

PRN321 

PRN322 

PRN323 

PRN324A 

PRN324B 

PRN324C 

PRN325A 

PRN325B 

PRN325C 

PRN331 

PRN332 

PRN333 

PRN334 

PRN335 

PRN336 



Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 



MA313 

MA314 

MA315 

MA321 

MA322 

MA323 

MA324A 

MA324B 

MA324C 

MA325A 

MA325B 

MA325C 

MA331 

MA332 

MA333 

MA334 

MA335 

MA336 



Table 


AD-HOC 


Edit Session 


SN311 






Edit Session 


SN312 






Edit Session 


SN313 






Edit Session 


SN314 






Edit Session 


SN315 


Table 


AIR-CTRL 


Edit Session 


SN151 


Table 


ANSWER 


Report Print 


PRN311 






Report Print 


PRN312 






Report Print 


PRN313 






Report Print 


PRN314 






Report Print 


PRN315 


Table 


DEPENDEN 


Edit Session 


SN12 






Edit Session 


SN1541 






Edit Session 


SN1542 






Edit Session 


SN1543 


Table 


DESCIPLN 


Edit Session 


SN13 




- 


Edit Session 


SN1551 






Edit Session 


SN1552 






Edit Session 


SN1553 


Table 


FITNESS 


Edit Session 


SN124 


Table 


LEAVE 


Edit Session 


SN22 


Table 


OJT-EVAL 


Edit Session 


SN141 






Edit Session 


SN1561 






Edit Session 


SN1562 






Edit Session 


SN1563 


Table 


PERSDUTY 


Edit Session 


SN11D 


Table 


PERSON 


Edit Session 


SN11A 






Edit Session 


SN1531 






Edit Session 


SN1532 
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Table PERSTATN 
Table PROMOTIO 

Table REQUEST 
Table T321 
Table T322 
Table T323 
Table T324A 
Table T324B 
Table T324C 
Table T325A 
Table T325B 
Table T325C 
Table T331 
Table T332 
Table T333 
Table T334 
Table T335 
Table T336 



Edit Session SN1533 
Edit Session SN11C 
Edit Session SN11B 
Edit Session SN152 
Edit Session SN21 
Report Print PRN321 
Report Print PRN322 
Report Print PRN323 
Report Print PRN324A 
Report Print PRN324B 
Report Print PRN324C 
Report Print PRN325A 
Report Print PRN325B 
Report Print PRN325C 
Report Print PRN331 
Report Print PRN332 
Report Print PRN333 
Report Print PRN334 
Report Print PRN335 
Report Print PRN336 
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APPENDIX I: PROCEDURES FOR INSTALLING AND OPERATING SPAS 



A. Installation Procedure 

To run any Paradox application, Paradox itself must be installed. To install Paradox 
the user has to run the Paradox installation program. Instructions for installing Paradox 
can be found in Paradox manuals. 

B. Setting up the SPAS application 

After installing Paradox you need to setup the SPAS application. This can be done 
in several ways. The suggested method from the DOS environment is described on the 
following page. Your SPAS application disk includes all required files and has one 
directory and two subdirectories. Figure 16 shows how the files are organized in the 
diskette. 




Figure 16:SPAS application disk hierarchy 
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From the DOS environment, insert the application disk into the floppy drive, and 
perform the following steps: 

1. Make sure that you are at the C:\PDOX40>. (If you are at the C:\>, type cd 
PDOX40 and then hit enter). 

2. Type md SPAS (creates the SPAS directory) 

3. Type cd SPAS (puts you in SPAS directory and displays the C:\PDOX40\SPAS> 
prompt) 

4. Type md CFG (creates the CFG directory) 

5. Type md WORKSHOP (creates the WORKSHOP directory) 

6. Type copy a:\spas\*.* c: (copies the files to hard disk) 

7. Type cd CFG (puts you in the CFG directory and displays the 
C:\PDOX40\SPAS\CFG> prompt) 

8 Type copy a:\spas\cfg\*.* c: (copies the files to hard disk) 

9 Type cd.. (you are at the C:\PDOX40\SPAS> prompt) 

10. Type cd WORKSHOP (puts you in the WORKSHOP directory and displays the 
C \PDOX40\SPAS\WORKSHOP> prompt) 

1 1 Type copy a:\spas\workshop\*.* c: (copies the files to hard disk) 

Now you have everything copied on your hard disk drive, and your application is 
ready to run. You can start running Paradox by typing "paradox" at the 
C:\PDOX40\SPAS> prompt. Figure 17 shows how your screen will look like 
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Figure 17: Paradox screen 



C. Using the SPAS application 

To run the SPAS application in the Paradox environment, you have to select the 
application from the pull-down menu bar. Using the mouse, click on the top left most 
field of the pull-down menu bar (indicated by three horizontal lines), then click on 
"Utilities", and then click on "Workshop". The working desktop now is the Paradox 
workshop. On the new desktop, click on "Application", then on "Directory", type 
c:\pdox40\spas and hit enter, or click on OK. Now you are at the application workspace. 
Click again on "Paradox Edit", "Scripts" and select "SPAS" from the scripts list. Finally 
click on "Play" and the SPAS application will be executed showing a screen that looks 
like figure 18. 
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Figure 18: SPAS screen 



1. Main menus 

The application has four main pull-down menus. Figure 18 shows the main 
menus named ’PERSONNEL SUBSYSTEM”, ’REQUEST SUBSYSTEM”, ’REPORT 
SUBSYSTEM", and "EXIT”. Each menu has submenus which in turn may have 
submenus The function of each menu is self descriptive. For more details refer to 
Appendix E. 
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2. Help screens 

Help screens are included in SPAS and are designed to help the user follow 
the right steps for each procedure. In this way the user can respond correctly to data 
entry and updates and eliminate potential mistakes. 

3. Printing outputs 

After performing a report operation from the report subsystem, there is a dialog box 
asking whether to print the results onto the screen, or to the printer. Choose the desired 
output media from this menu. 
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